• Advertisement
Sign in to follow this  

vector::clear() necessary?

This topic is 4262 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

I have an stl vector array which stores the pointers to objects. To delete the array i am using: std::vector<*foo> bar; ... for (vector<*foo>::iterator itr = bar.begin(); itr != bar.end(); ) { delete itr; itr = NULL; } Do i need to clear the bar array after this using bar.clear(); if i do not use bar.clear() waht could be the implications.

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
You would have a vector full of null pointers.

Share this post


Link to post
Share on other sites
Quote:
Original post by rish2005
for (vector<*foo>::iterator itr = bar.begin(); itr != bar.end(); )
{
delete itr;
itr = NULL;
}
That doesn't look right. I would think you'd want:
for (vector<*foo>::iterator itr = bar.begin(); itr != bar.end(); ++itr)
{
delete (*itr);
}
In any case, it's not strictly necessary to call clear() after performing this step; the memory allocated by the vector itself will be released when the vector goes out of scope.

Share this post


Link to post
Share on other sites
You may want to consider a vector of smart pointers a boost::ptr_vector instead of a std::vector of raw pointers.

Share this post


Link to post
Share on other sites
I agree with jyk and SiCrane but do consider, which I think the AP might have been trying to point out, that if that vector is not going out of scope and there is ANY possibility that you might be checking it agiain, then you definately want to clear it.

You dont want to end up trying to access those null pointers later on down the line and not knowing why the heck its crashing.

Share this post


Link to post
Share on other sites
Well I always clear the array, after deallocating it. Because I just want to be sure that I can't access those NULL pointers.

The only thing I can think of(at this point)why you wouldn't want to clear it, is when you insert new items to the vector.

GBS

Share this post


Link to post
Share on other sites
Uh, I surely can't be the only one to notice that 'vector<*foo>' should be 'vector<foo*>'? :s

Share this post


Link to post
Share on other sites
Quote:
Original post by Zahlman
Uh, I surely can't be the only one to notice that 'vector<*foo>' should be 'vector<foo*>'? :s


I myself would use foo* too, is *foo legal? If so, is there a difference?

Share this post


Link to post
Share on other sites
no its not legal (you cant dereference a data type, only a pointer to an allocated instance of a data type) in that case... its a typo none of us caught.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by jyk
Quote:
Original post by rish2005
for (vector<*foo>::iterator itr = bar.begin(); itr != bar.end(); )
{
delete itr;
itr = NULL;
}
That doesn't look right. I would think you'd want:for (vector<*foo>::iterator itr = bar.begin(); itr != bar.end(); ++itr)
{
delete (*itr);
}In any case, it's not strictly necessary to call clear() after performing this step; the memory allocated by the vector itself will be released when the vector goes out of scope.


Is this valid??
when using a std::map it has a special property that deleting an element does not invalidate the iterator, but this is not the case which a vector. If you delete the element pointed to by the iterator can you then increment the iterator??

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
If you delete the element pointed to by the iterator can you then increment the iterator??


No, but he's not deleting the element. The element in this case is the pointer, and it still exists within the container. The object being pointed at by the contained pointer (which is in turn pointed at by the iterator) is being deleted:
container  -->   element[0]
element[1]
...
element[n]
^
|
added/deleted with ...::insert, remove, pop_back, etc
can/will invalidate iterators depending on container


When container holds pointers...


container --> element[0] --> object
element[1] --> object
...
element[n] --> object
^
|
created/destroyed with new, delete, etc
will not invalidate iterators

Share this post


Link to post
Share on other sites
Quote:
Original post by MaulingMonkey
Quote:
Original post by Anonymous Poster
If you delete the element pointed to by the iterator can you then increment the iterator??


No, but he's not deleting the element. The element in this case is the pointer, and it still exists within the container. The object being pointed at by the contained pointer (which is in turn pointed at by the iterator) is being deleted:
container  -->   element[0]
element[1]
...
element[n]
^
|
added/deleted with ...::insert, remove, pop_back, etc
can/will invalidate iterators depending on container


When container holds pointers...


container --> element[0] --> object
element[1] --> object
...
element[n] --> object
^
|
created/destroyed with new, delete, etc
will not invalidate iterators


just for completeness of a great explanation ;-) ...

even if he was deleting the data pointed to by the iterators through the use of erase or remove (depending on the container), these functions return an iterator to the next position which should be assigned back to the same iterator. This allows it to be incremented as long as you check that its not pointing to the end of the container.

if the iterator actually points to a pointer as above then it should obviously be freed before doing this, since you would be removing the actual pointer.

Share this post


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

  • Advertisement