Valid STL-do not put auto_ptr in the container

 

 

Frankly speaking, this clause does not need to appear in valid STL. Auto_ptr containers (coaps) are forbidden. None of the Code that tries to use them can be compiled. The C ++ Standards Committee has spent countless efforts to arrange this situation [1]. I didn't need to talk about anything about coaps, because your compiler should have a lot of complaints about such containers, and none of them can be compiled.

 

Alas, many programmers will not reject coaps when using the STL platform. What's worse, many Programmers think of coaps as a simple, direct, and efficient solution for frequent accompanied pointer container (see articles 7 and 33) resource leaks. As a result, many programmers are tempted to use coaps, even if they cannot be established successfully.

 

I will immediately explain how worried coaps are, so that the Standardization Board takes special measures to ensure that they are illegal. Now, I want to focus on a disadvantage that does not require auto_ptr or even container knowledge: coaps cannot be transplanted. What can they do? The C ++ standard prohibits them. A good STL platform has been implemented. There is enough reason to infer that over time, STL platforms that cannot implement standards will become more adaptive and when that happens, code using coaps will be more portable than it is now. If you attach importance to portability (and you should be), you will reject coaps only because of the failure of their porting test.

However, you may not have the idea of portability. If so, let me remind you to copy the unique definition of auto_ptr-some people say it is singular.

When you copy an auto_ptr, the ownership of the object pointed to by auto_ptr is transferred to the copied auto_ptr, And the copied auto_ptr is set to null. You should say it again correctly:Copying an auto_ptr will change its value.:

Auto_ptr <widget> pw1 (new widget); // pw1 points to a widget auto_ptr <widget> pw2 (pw1); // pw2 points to the widget of pw1; // pw1 is set to null. (The ownership of the widget is transferred from pw1 to pw2 .) Pw1 = pw2; // pw1 now points to the widget again; // pw2 is set to null

This is very unusual, maybe it is interesting, but you (as an STL user) care about it because it leads to some very surprising behavior. For example, consider this code that looks very correct. It creates a vector of auto_ptr <widget> and then sorts it by using a function that compares the values of the widgets that point to it.

Bool widgetapcompare (const auto_ptr <widget> & LHS, const auto_ptr <widget> & RHs) {return * LHS <* RHS; // for this example, suppose the widget} // operator <vector <auto_ptr <widget> widgets; // create a vector and then // fill it with the auto_ptr of the widget; // remember thisNoCompile! Sort (Widgets. Begin (), Widgets. End (), // sort the vector widgetapcompare );

Everything here seems reasonable and conceptual, but the results are completely unreasonable. For example, one or more auto_ptr values in Widgets may have been set to null during sorting. Sorting this vector may have changed its content! It is worth understanding how this happened.

This is because the method that implements sort-a common method, as it presents-is a variant of the fast sort algorithm. We don't care about the advantages of fast sorting, but the basic idea of sorting a container is to select an element of the container as the "Principal Component" and then perform recursive sorting on values greater than or less than or equal to the principal component. In sort, this method looks more or less like this:

Template <class randomaccessiterator, // This sort Declaration class compare> // directly comes from the standard void sort (randomaccessiterator first, randomaccessiterator last, compare comp) {// This typedef explains typedef typename iterator_traits <randomaccessiterator>: value_type elementtype; randomaccessiterator I ;... // point I to the principal element elementtype effectvalue (*); // copy the principal element to a // local temporary variable. For more information, see... // do the rest of the sorting work}

Unless you are experienced in reading STL source code, it may seem a little troublesome, but it is not bad. The only difficulty is that iterator_traits <randomaccessiterator>: value_type is referenced, but it is only a strange STL method of the object type pointed to by the sort iterator. (When we involve iterator_traits <randomaccessiterator>: value_type, we must write typename before it because it is a name dependent on the template parameter type. Here it is randomaccessiterator. For more information about typename usage, go to the 7th page .)

This line is tricky in the code above,

ElementType pivotValue(*i);

Because it copies an element from the saved interval to a local temporary object. In our example, this element is an auto_ptr <widget>, so this copy operation silently sets the one in the copied auto_ptr -- vector to null. In addition, when tvalue has a lifetime, it automatically deletes the widget to which it points. In this case, the sort call returns, the content of the vector has changed, and at least one widget has been deleted. There may also be several vector elements that have been set to null, and several widgets have been deleted, because quick sorting is a recursive algorithm, and each layer of recursion copies a principal component.

This falls into a very annoying trap, which is why the Standards Committee is so hard to ensure that you will not fall into it. By never building an auto_ptr container to respect its work for your interests, even if your STL platform allows that.

If your target is a smart pointer container, this does not mean you are unlucky. Smart pointer containers are good.