• Advertisement
Sign in to follow this  

STL Vector reference ?is that ok?

This topic is 4727 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

CFace &s = m_Faces[0]; is it ok to access the elements of a STL vector that way? or do i create some side by effects that i am not aware of?

Share this post


Link to post
Share on other sites
Advertisement
Thats okay, use constant references you if your not going modify the state of the instance, remember constant correct-ness it pays back :P

Really the preferred method is to use nested typedefs provided by an STL container e.g.


typedef std::vector<CFace> CFaces;

CFaces::reference s = m_Faces[0];

or


CFaces::const_reference s = m_Faces[0];


Because for some containers a reference may not be a really a reference but a proxy reference that pretends to be a reference type :P but this isn't usually the case for std::vector except when it comes to std::vector<bool> :P.

Share this post


Link to post
Share on other sites
Your reference will become invalid if the vector elements are moved (caused basically by inserting or erasing elements in the vector, or by calls to resize functions).

And of course, it will also become invalid if the vector is destroyed.

Share this post


Link to post
Share on other sites
Quote:
Original post by snk_kid
Because for some containers a reference may not be a really a reference but a proxy reference that pretends to be a reference type :P but this isn't usually the case for std::vector except when it comes to std::vector<bool> :P.

Actually, a container's nested reference type can't be a proxy according to the standard, so you can safely just manually use a reference. This is one of the reasons that ::std::vector< bool > is not actually an stl container.

Share this post


Link to post
Share on other sites
Quote:
Original post by Polymorphic OOP
Quote:
Original post by snk_kid
Because for some containers a reference may not be a really a reference but a proxy reference that pretends to be a reference type :P but this isn't usually the case for std::vector except when it comes to std::vector<bool> :P.

Actually, a container's nested reference type can't be a proxy according to the standard, so you can safely just manually use a reference. This is one of the reasons that ::std::vector< bool > is not actually an stl container.


Thanks for pointing that out Poly.

Share this post


Link to post
Share on other sites
ok thx guys

btw i only use push routines to add a element to the top*the last* position of the vector

i also have a build in mechanism that checks if i have at least 1 element free in the vector otherwise it will resize the vector to .capacity() + 4;
so i don t reallocate everytime i add a new element, but instead reallocate if needed and that at the end of a modification

Share this post


Link to post
Share on other sites
Quote:
Original post by Basiror
ok thx guys

btw i only use push routines to add a element to the top*the last* position of the vector

i also have a build in mechanism that checks if i have at least 1 element free in the vector otherwise it will resize the vector to .capacity() + 4;
so i don t reallocate everytime i add a new element, but instead reallocate if needed and that at the end of a modification


If you don't need contiguously of memory you might want to consider using std::deque instead, its also a random accessible container.

Share this post


Link to post
Share on other sites
std::vector already manages resizing internally, so if you insert an object and there is no room left for it, the vector will automatically resize itself to twice its initial size (the factor is implementation-dependent) to be able to store the additional object.

Share this post


Link to post
Share on other sites
well but if i have a mesh with 500 vertices and the vector is full it resizes to 1000 vertices although i just add one or two additional vertices

that a wast of memory in my eyes

Share this post


Link to post
Share on other sites
Quote:
Original post by Basiror
well but if i have a mesh with 500 vertices and the vector is full it resizes to 1000 vertices although i just add one or two additional vertices

that a wast of memory in my eyes


If you know in advance you can use vector's "reserve" method to allocate a chunk of uninitialized memory then use push_back.

Share this post


Link to post
Share on other sites
yes i will use this as well for example when merging several selected meshes and such but for primitives like brushes and so on i will use my build in mechanism

Share this post


Link to post
Share on other sites
Quote:
Original post by Basiror
well but if i have a mesh with 500 vertices and the vector is full it resizes to 1000 vertices although i just add one or two additional vertices

that a wast of memory in my eyes


It's done for efficiency. If it used exactly what was needed, it would need to reallocate the memory and copy everything over 500 times. By doubling, it only had to move everything over 10 times. And if you told it in the first place how many elements you were going to need, it would only have to do it once.

Share this post


Link to post
Share on other sites
Reserve more than enough.

Once you have put everything you need in it, shrink it to fit the data.

Nothing wasted, except for processing time.

It's a trade-off.

You're the engineer, you make the decision.

Share this post


Link to post
Share on other sites
i reserve a number of elements that is large enough to hold the number of vertices i will have in the majority of case but the shrinking back to whats needed approach is indeed something i will build in when i deselect a object

Share this post


Link to post
Share on other sites

template<typename Cont>
void shrink(Cont& cont) {
Cont(cont).swap(cont);
}

//usage

vector<int> myInts;
//...
shrink(myInts);

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement