Sign in to follow this  
daniel_i_l

std vector dtor

Recommended Posts

Could you post some sample code? Your question isn't very clear.


Generally though, if I understood you correctly:

- If it's a vector of non-pointers, then everything should be dealt with for you.

- If it's a vector of pointers, then you will need to free all the resources that you allocated, or use a container of smart pointers (e.g. std::vector< boost::shared_ptr< Type > >) or a pointer container (e.g. boost::ptr_vector< Type >).


jfl.

Share this post


Link to post
Share on other sites
Quote:
Original post by daniel_i_l
If i allocate a std vector with push_back do i have to clear it in the dtor of my class?
Thanks.


No. std::vector's destructor automatically clears it's elements itself. This is part of a powerful, and basically necessary for sane exception safety, idiom known as Resource Acquisition Is Initialization (RAII for short).

Basically, the innermost class that handles a resource (that is, keeps track of it's allocation) must clean up said resource.

std::vector will clean up it's elements, std::ofstream will close it's file, std::auto_ptr will delete the item it points at. This means less code that needs to be repeated - and thus fewer leaks and related mistakes.

Note that these resources are usually very specific. For example, the STL containers, when using pointers, will only clean up the pointers they "contain" - they will not delete the objects they point to. So, this would leak:

class foo {
std::vector< int* > data;
public:
foo() {
data.push_back( new int( 42 ) );
data.push_back( new int( 69 ) );
}
~foo() {
//the pointers of type "(int*)" are destroyed by std::vector
//however, the two ints of type "(int)" - note that this exactly matches the non-brace/value bit of the new invocation - are *NOT*
//You must *delete* *each one* - same applies for pointers about to be .clear()ed, .resize()ed, and/or .pop_back()ed
}
};






Note that things like the above are common (for polymorphism) enough that libraries have been made to tackle these exact problems:

The Boost Libraries collection has a similar class, boost::ptr_vector, which *does* automatically delete.

There is also std::auto_ptr and multiple similar boost classes designed for slightly different roles or safety purpouses (such as boost::intrusive_ptr) - although not all will work with containers (std::auto_ptr and boost::scoped_ptr/_array will not work, for example).

EDIT: Clarification, and fixing blatent lies mistakenly made after being awake around 40+ hours. Hopefully, this critical hit against the dead horse we're beating which both solves your original quandry and gives you deeper insight into the design, rationale, and patterns of the standard C++ library. If it dosn't, feel free to clarify what you're talking about, I only pretend to read minds.

Share this post


Link to post
Share on other sites
It's really quite simple.

If the chunk of memory in question is allocated for the reason that you explicitly allocated it (via 'new' or 'new[]'), then deallocate it (via 'delete' or 'delete[]' accordingly - and they MUST match).

If it was allocated by someone else's code, then that code is responsible. In the case of the standard library, the standard library correctly accepts its responsibility, by using the destructor of the std::vector object to deallocate the memory of the vector.

If you have a vector of pointers to things, then "under the hood" the vector has an array-allocation of pointers to things. It will deallocate that array-allocation, because it allocated that. You must deallocate the pointed-at things (IF they are things that were allocated), because you allocated them.

Note that multiple pointers could point to the same allocated thing. Each *allocation* needs to be deallocated, NOT "each pointer that points at an allocated thing". Remember, delete and delete[] deallocate the pointed-at thing. If someone else was pointing at it, someone else still "points at it" - except "it" is gone (i.e. the pointer is "dangling", and trying to use it will cause undefined behaviour).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this