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.

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 on other sites
You would have a vector full of null pointers.

Share on other sites
Quote:
 Original post by rish2005for (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 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 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 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 on other sites
Uh, I surely can't be the only one to notice that 'vector<*foo>' should be 'vector<foo*>'? :s

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

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

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 on other sites
Quote:
Original post by jyk
Quote:
 Original post by rish2005for (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 on other sites
Quote:
 Original post by Anonymous PosterIf 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 on other sites
Quote:
Original post by MaulingMonkey
Quote:
 Original post by Anonymous PosterIf 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.