Use of auto_ptr

Hi all!

I just read in Meyers, Effective c++ 3rd Edition about resource management. Item 13 describes what I find very interesting, the std::auto_ptr.

I have myself experienced resource leaks due to unexcepted program termination, unexpected thread termination and so on. To avoid these problems auto pointers seems to be just perfect! Is that right?

I guess its not always recommended to use auto_ptr, then my question is when should it be used and when should it not?

It would be tempting to start to use auto_ptr whenever I am using a pointer, but that could not be right.

What I am actually questioning is a little more discussion about when to use this wonderful? auto_ptrs?

Thx
Laitinen

auto_ptr needs to be handled with care. Read Meyers very carefully on the subject. Points to note:

- You cannot use auto_ptrs in an STL container
- Beware of passing auto_ptrs to functions by value
- If you have an auto_ptr member, you will need a user-defined copy constructor and copy assignment operator (or disable them)
- You can't use them to point to an array (i.e. don't use them to hold anything that's been allocated with new[]).

That said, they have their uses, but you may want to explore the various smart pointers offered by boost. Note also that not every pointer in a typical program is suitable for being wrapped in a smart pointer.

And, don't forget the ownership semantics of auto_ptr, and the ownership transfer semantics of copy and assignment of auto_ptrs.

There are many pointer scenarii that auto_ptr just don't handle correctly. In that case, you can use other more appropriates smart pointers, such as smart pointers of TR1 or boost. And, sometimes, if none of these smart pointers is appropriate (shared_ptr is quite universally good) you can either program your own smart pointers for your particular scenario, or craft another existing parametrizable smart pointer, or directly use plain old pointers.

smart pointers are suitable for people that use c++ because of necessity or to look good when they should be using managed c++ or c#. definitely single thread and limited run-time decisions.

Kuphryn

Quote:

---

Originally Posted by kuphryn

smart pointers are suitable for people that use c++ because of necessity or to look good when they should be using managed c++ or c#. definitely single thread and limited run-time decisions.

Kuphryn

---

It's not to "look good". It's RAII.

We should not be using managed C++ or C#.

smart pointers work find in multi-threaded environments.

I don't know what you could possibly mean by "limited run-time decisions."

Jeff

Take a look at the links in the this post.. - http://www.codeguru.com/forum/showpo...1&postcount=12 there's one item by herb sutter as well. You should get the idea - in fact EC++ item should have helped you as well. Take a re-read if you feel necessary. One example application can be this:

Code:

---

struct One
{
      explicit One(int i){//no problem .. cool constructor}
      //other members
};
struct Two
{
      explicit Two(char c){throw std::runtime_error();}  //problematic constructor throws exception
      //other members
};

struct A
{
        A(int a, char c)
        {
              std::auto_ptr<One> autoptrToOne(new One(a));
              std::auto_ptr<Two> autoptrToTwo(new Two(c));
              ptrToOne = autoptrToOne.release();  //can use member get() too
              ptrToTwo = autoptrToTwo.release();  //can use member get() too
        }
        //non-autoptr version
        A(int a, char c)
        {
              ptrToOne = new One(a);  //happens successfully 
              ptrToTwo = new Two(c);  //fails - throws exception - what happens to dynamic allocation made for One? memory leak!!!
        }       
    private:
        One* ptrToOne;
        Two* ptrToTwo;
};

---

(untested/uncompiled code just for illustration)

Take a look at the above code. See how auto_ptr make it safe to have multiple dynamic allocations safely rolled-back when one of those later ones throws and exception.

Further to the other comments, I think you should generally only use auto_ptr in three contexts:

1. As a function parameter, where you are explicitly passing ownership of a newed pointer to the function.
2. As the return type of a function, where the function explicitly passes ownership of a newed pointer to the caller. An alternative to this is to pass an auto_ptr by reference as an "out" parameter.
3. To ensure clean up of a pointer via "delete" on exit from a code block.

In general I would not advocate using it in any other context, such as as a member variable of an object, or in a container (which in fact usually won't compile). Other smart pointer classes with different copying semantics are more appropriate or correct in those contexts.

In addition to the three main examples given by TomWidmer, as a const non-static data member of a non-copyable class, an auto_ptr makes sense. const auto_ptr have no ownership transfer semantics, since they're non-copyable, non-assignable, and thus, it's just a simple fixed ownership semantic.

Still, in that case, boost::scoped_ptr is slightly less error prone (actually, that's true of my usage 3 as well). Also, it's ok as a non-const member of a non-copyable class too, isn't it? e.g.

Code:

---

void Foo::setBar(std::auto_ptr<Bar> pBar)
{
  m_bar = pBar; //deletes old m_bar, if there was one.
}

---

Quote:

---

Originally Posted by TomWidmer

Also, it's ok as a non-const member of a non-copyable class too, isn't it? e.g.

---

Yes.

Why can't it be a member of a copyable class??? If you write your copy constructor and assignment operators to create new auto_ptr's, I don't see why there would be a problem? What's the difference between this and copying a class with regular pointers? You just do deep copies!

Code:

---

#include <memory>
class A
{

public:

A (const long& value) : _p (new long) { *_p = value; }
 
A (const A& rhs) : _p (new long) { *_p = *(rhs._p); }

private:

std::auto_ptr<long> _p;

};
 
int main ()
{

A a1 (10);
A a2 (a1);
 
return 0;

}

---

Quote:

---

Originally Posted by kuphryn

smart pointers are suitable for people that use c++ because of necessity or to look good when they should be using managed c++ or c#. definitely single thread and limited run-time decisions.

Kuphryn

---

Ehh what?

What are you trying to tell us? It looks like a rant but it might not be and I don't understand the conclusion: "definitely single thread and limited run-time decisions."

No flame, just wondering what is going through your mind.

In response to the OP: as you can see from the number of responses using std::auto_ptr<> might require some thought but IMO learning the semantics of std::auto_ptr<>, boost::shared_ptr<> and boost::weak_ptr<> is time well spent as it will make your code less likely to leak resources and yet doesn't add much typing overhead.

Hope this helps.

PS. Some (not in this thread and not on codeguru) have recommended not using std::auto_ptr<> at all because of the strange "copy" semantics and only use boost::shared_ptr<> and their likes. I wouldn't say that though. Sometimes std::auto_ptr<> is exactly the right tool. One of the reasons is that it's very lightweight in terms of overhead.

Quote:

---

Originally Posted by sszd

Why can't it be a member of a copyable class??? If you write your copy constructor and assignment operators to create new auto_ptr's, I don't see why there would be a problem?

---

I didn't said it had any problem. I was only giving a more typical usage (which didn't required any user-defined copy-constructor or destructor).

Quote:

---

Originally Posted by sszd

What's the difference between this and copying a class with regular pointers? You just do deep copies!

Code:

---

#include <memory>
class A
{

public:

A (const long& value) : _p (new long) { *_p = value; }
 
A (const A& rhs) : _p (new long) { *_p = *(rhs._p); }

private:

std::auto_ptr<long> _p;

};
 
int main ()
{

A a1 (10);
A a2 (a1);
 
return 0;

}

---

---

Well, you forgot to overload the copy-assignment operator...
And your example doesn't show a useful usage, though, I know there are real usages of it. :p

Quote:

---

Originally Posted by sszd

Why can't it be a member of a copyable class??? If you write your copy constructor and assignment operators to create new auto_ptr's, I don't see why there would be a problem? ...

---

Of course you could be using std::auto_ptr<> in that scenario but IMO it would be better to use a scope guard that has the desired semantics ie in your case some sort of copy_ptr och clone_ptr. It's also less error prone because it won't backfire like std::auto_ptr<> does if you forgot to write your own copy constructor/assigment operator.

Hope this helps

Quote:

---

Originally Posted by SuperKoko

Well, you forgot to overload the copy-assignment operator...
And your example doesn't show a useful usage, though, I know there are real usages of it. :p

---

This was only an example of how to copy an auto_ptr, it wasn't meant for anything other than an illustration. I assumed one would be able to extrapolate a copy-assignment operator;).

Of course you can use an auto_ptr pretty much anywhere you can use a normal pointer (with careful use of release() etc.), it's just that there are better alternatives in most cases. If you don't use any smart pointers other than auto_ptr and shared_ptr, then you might be inclined to use auto_ptr in a lot more circumstances than if you have a suite of smart pointers to choose from.

For example, if you want deep copy semantics, use a cloning pointer, if you need shared sematics, use shared_ptr, if you don't want copyability, use scoped_ptr. That leaves auto_ptr with ownership passing as its main speciality (e.g. as function parameters and returns), on which a lot of design time was spent to make sure it works (which it doesn't perfectly). However, it's likely to lose that role to move_ptr in the future, when move semantics are added to C++. That will leave it as the default scoped pointer for those not using boost or their own smart pointers, but without many other uses.

Check out the following link on smart pointers:
http://axter.com/smartptr

The above link include a smart pointer that can be used in a vector, and additional information on different types of smart pointers.