Effective STL 7th: If the container contains a pointer created by the new operation, remember to delete the pointer before the container object is refactored

The containers in the STL are fairly "smart", providing iterators for backward and forward traversal (through begin, end, Rbegin, etc.), which tell you which types of elements are included (defined by their value_type type); During insertions and deletions, They do the necessary memory management themselves, they report how many objects they have, how many objects they can hold (by size and max_size, respectively), and, of course, when they are themselves refactored, they automatically deconstruct each of the objects contained.

With such a "smart" container, many programmers no longer consider themselves doing cleanup work. What's worse, they think that containers will consider doing these things for them. In many cases, they are right. But when a container contains pointers that are assigned in new ways, they don't think so. Yes, the pointer container will deconstruct every element it contains when it is refactored, but the pointer's destructor does nothing! It certainly does not call delete.

As a result, the following code directly leads to resource leaks:

       void DoSomething ()       {             vector<widget*>vwp;              for (int I = 0; I < Some_magic_number; ++i)              {                     vwp.push_back (new Widget);                     ...              }                                                A widget resource leak has occurred here       }

When the scope of the VWP ends, its elements are all refactored, but the fact that the object created by new is not deleted is not changed. It is your responsibility to delete these objects, not the responsibility of the vectors. This is the character of the vector. Only you will know if these pointers should be released.

void DoSomething () {for (Vector<widget*>::iterator i = Vwp.begin (); I! = Vwp.end (); ++i) delete *i;}

This will work, but only when you're less picky about "can do". One problem is that the new for loop does the same thing as For_each, but it's better to use For_each to look so clear. The problem is that this code is not exceptionally secure. There is also a resource leak if there is an exception thrown between the two procedures in which you want to populate the pointer and remove the pointer from the VWP.

One solution is as follows:

       struct DeleteObject       {              template<typename t>              void operator () (const t* PTR) const              {                     Delete ptr ;              }       };       void DoSomething ()       {              deque<specialstring*> dssp;              For_each (Dssp.begin (), Dssp.end (), DeleteObject ());       

But it's still not exceptionally safe. If an exception is thrown when the specialstring has been created and the call to For_each has not started, a resource leak occurs.

Second Solution:

Use the shared_ptr in the Boost library.

       void DoSomething ()       {              typedef boost::shared_ptr<widget> SPW;   spw= "shared_ptr" pointing to the widget              vector<spw> vwp;              for (int I = 0; I < Some_magic_number; ++i)                     Vwp.push_back (SPW (new Widget));                     ...       }      There will be no widget leaks, even if an exception is thrown in the code above

Never mistakenly think: You can make the pointer be automatically deleted by creating a auto_ptr container. The idea is dangerous, see effective STL 8th for specific explanations.

What you have to remember is that the STL container is smart, but not intelligent to the extent that you know whether to delete the pointers that you contain. When you use the pointer's container, and the pointer should be deleted, you must either replace the pointer with a smart pointer object (such as Boost shared_ptr) in a reference-count form, or delete each of the pointers manually when the container is refactored, in order to avoid resource leaks.

Effective STL 7th: If the container contains a pointer created by the new operation, remember to delete the pointer before the container object is refactored