Is it safe to store objects of a class which has an std::auto_ptr as its member variable in std::vector?

Question

I can't use shared_ptr in my project, no boost :(

So, I'm having a class roughly similar to the one below:

class MyClass
{
private:
  std::auto_ptr<MyOtherClass> obj;
};

Now, I want to store the instances of above class in std::vector. Is it safe? I've read here that it's wrong to use std::auto_ptr with STL containers. Does it apply to my situation here?

Answer 1

I've posted a question as a follow-up to this answer, see http://stackoverflow.com/questions/704780/class-containing-autoptr-stored-in-vector.

Assming your class does not have a user-defined copy constructor, then no, it is probably (see below) not safe. When your class is copied (as will happen when it is added to a vector) the copy constructor of the auto_ptr will be used. This has the weird behaviour of tranferring ownership of the thing being copied to the copy and, so the thing being copied's pointer is now null.

It is possible, though unlikely, that you actually want this behaviour, in which case an auto_ptr is safe. Assuming you do not, you should either:

• add a copy constructor to manage the copying

Note this is not enough - see the follow-up question mentioned above for more info.

or:

• use a smarter, possibly reference counted pointer, such as one of the boost smart pointers

Answer 2

Copying MyClass object will cause either call to assignment operator or copy constructor. If they are not overloaded to handle auto_ptr<> in unusual way, they will propagate the call to copy constructor (or assignment operator) to the auto_ptr<> member. This may lead to problems described in question you had linked.

Answer 3

It is not safe, bacause when container will copy MyClass instnace default copy operator will call copy for all members - and for auto_ptr member too and we will have same situation as you describe in your question ( storing auto_ptr in container )

BTW: for avoid confusion at compile time add

private:
  MyClass& operator=( const MyClass& );  
  MyClass( const MyClass& );

compiler output error if you will try use copy operators, this can save you from hours of debug.

Answer 4

It will not work. auto_ptr doesn't count references which means at the first destructor call your pointer will be freed.

Use boost::shared_ptr instead.

Answer 5

The reason why it is not safe to instanciate a vector of auto_pointer is that there is an algorithm : sort(), that will do a copy of one object in your container on the stack. (sort() implements quicksort which needs a "pivot") And therefore deleting it when going out of scpope of the sort() function. As well any algorithm, or function of your own that are able to take your container as parameter, and copy one of its object on the stack will cause this issue as a result.

Well in your case, it is simple you must ensure your class does not behaves as an auto_ptr, or ensure you will never call such function/algorithm that can delete your underlying objects. The first solution is best, according to me :)

So your copy constructor and your affectation operator as well, should not give away property of the pointer object.

The best way to achieve that is to wrapp a boost smart pointer instead of an auto_ptr, to make your container safe when calling such function/algorithm.

By the way according to me, defining a better copy constructor/affectation operator to bypass this issue is not a good solution: I can't see a good copy constructor implementation (and affectation operator as well) that could keep safe the result of applying the sort() algorithm.

Answer 6

As Neil Butterworth said, auto_ptr is probably not the way to go.

boost::shared_ptr clearly is, but you say you can't use boost.

Let me mention that you could download boost, extract what you need for shared\ptr only using the bcp tool and use boost::shared_ptr. It would only mean a few added hpp files in your project. I believe it's the right way to go.

Answer 7

It is not valid to have an object that contains an auto_ptr in a standard container. You run into undefined behavior. Two common problems:

• std::vector<>::resize copies its argument into each created element. The first copy will "succeed" (see below why not), but each further copy will be empty, because the element copied is also empty!
• If something during reallocation throws, you can happen to have some elements copied (to a new buffer) - but the copy being thrown away - and other elements not, because push_back must not have any effects if an exception is being thrown. Thus some of your elements are now empty.

As this is all about undefined behavior it does not really matter. But even if we try to come up with this behavior based on what we think is valid, we would fail anyway. All the member functions like push_back, resize and so on have a const reference that takes an object of type T. Thus, a reference of type T const& is tried to copied into elements of the vector. But the implicitly created copy constructor/copy assignment operator looks like T(T&) - that is, it requires a non-const object to be copied from! Good implementations of the Standard library check that, and fail to compile if necessary.

Until the next C++ version, you have to live with this. The next one will support element types that are merely movable. That is, a moved object does not need to be equal to the object moved to. That will allow putting streams, transfer-of-ownership pointers and threads into containers.

See what the Standard says for this (17.4.3.6):

In certain cases (replacement functions, handler functions, operations on types used to instantiate standard library template components), the C++ Standard Library depends on components supplied by a C++ program. If these components do not meet their requirements, the Standard places no requirements on the implementation.

In particular, the effects are undefined in the following cases:

• for types used as template arguments when instantiating a template component, if the operations on the type do not implement the semantics of the applicable Requirements subclause (20.1.5, 23.1, 24.1, 26.1).

Answer 8

If you want to use a class that uses auto_ptr in a container, you can just provide a copy-constructor and assignment operator yourself:

class MyClass
{
private:
  const std::auto_ptr<MyOtherClass> obj; // Note const here to keep the pointer from being modified.

public:
  MyClass(const MyClass &other) : obj(new MyOtherClass(*other.obj)) {}
  MyClass &operator=(const MyClass &other)
  {
      *obj = *other.obj;
      return *this;
  }
};

But as mentioned elsewhere, the standard lets containers make copies and assignments and assumes that the contained classes will behave in a specific manner that auto_ptr violates. By defining the methods above, you can make a class that contains an auto_ptr behave. Even if your implementation works fine with auto_ptrs, you run the risk of finding another implementation doesn't work. The standard only make guarantees of performance and observable behaviour, not implementation.