Explaining all of the fun and delicious things that can
+ happen with misuse of the auto_ptr class
+ template (called AP here) would take some
+ time. Suffice it to say that the use of AP
+ safely in the presence of copying has some subtleties.
+
+ The AP class is a really + nifty idea for a smart pointer, but it is one of the dumbest of + all the smart pointers -- and that's fine. +
+ AP is not meant to be a supersmart solution to all resource + leaks everywhere. Neither is it meant to be an effective form + of garbage collection (although it can help, a little bit). + And it can notbe used for arrays! +
+ AP is meant to prevent nasty leaks in the + presence of exceptions. That's all. This + code is AP-friendly: +
+ // Not a recommend naming scheme, but good for web-based FAQs.
+ typedef std::auto_ptr<MyClass> APMC;
+
+ extern function_taking_MyClass_pointer (MyClass*);
+ extern some_throwable_function ();
+
+ void func (int data)
+ {
+ APMC ap (new MyClass(data));
+
+ some_throwable_function(); // this will throw an exception
+
+ function_taking_MyClass_pointer (ap.get());
+ }
+ When an exception gets thrown, the instance of MyClass that's
+ been created on the heap will be delete'd as the stack is
+ unwound past func().
+
Changing that code as follows is not AP-friendly: +
+ APMC ap (new MyClass[22]); +
You will get the same problems as you would without the use + of AP: +
+ char* array = new char[10]; // array new... + ... + delete array; // ...but single-object delete +
+ AP cannot tell whether the pointer you've passed at creation points
+ to one or many things. If it points to many things, you are about
+ to die. AP is trivial to write, however, so you could write your
+ own auto_array_ptr for that situation (in fact, this has
+ been done many times; check the mailing lists, Usenet, Boost, etc).
+
+
All of the containers + described in the standard library require their contained types + to have, among other things, a copy constructor like this: +
+ struct My_Type
+ {
+ My_Type (My_Type const&);
+ };
+
+ Note the const keyword; the object being copied shouldn't change.
+ The template class auto_ptr (called AP here) does not
+ meet this requirement. Creating a new AP by copying an existing
+ one transfers ownership of the pointed-to object, which means that
+ the AP being copied must change, which in turn means that the
+ copy ctors of AP do not take const objects.
+
+ The resulting rule is simple: Never ever use a + container of auto_ptr objects. The standard says that + âundefinedâ behavior is the result, but it is + guaranteed to be messy. +
+ To prevent you from doing this to yourself, the + concept checks built + in to this implementation will issue an error if you try to + compile code like this: +
+ #include <vector>
+ #include <memory>
+
+ void f()
+ {
+ std::vector< std::auto_ptr<int> > vec_ap_int;
+ }
+ +Should you try this with the checks enabled, you will see an error. +