shared_ptr vs std::auto_ptr

Hello !

When a ref. counted smart pointer (template) class is available (like
boost::shared_ptr), is there any (semantic) reason to still use
std::auto_ptr rather than this smart pointer ? Or should one use shared_ptr
for every cases ?

Thanks in advance for your remarks !

SerGioGio

re: shared_ptr vs std::auto_ptr

In article <be15mu$i0g$1@news-reader3.wanadoo.fr>, SerGioGio
<sergiogiogio@yahoo.fr> wrote:

| Hello !
|
| When a ref. counted smart pointer (template) class is available (like
| boost::shared_ptr), is there any (semantic) reason to still use
| std::auto_ptr rather than this smart pointer ? Or should one use shared_ptr
| for every cases ?
|
| Thanks in advance for your remarks !

There may be cases in your code where you do not want to have the
semantics of more than one smart pointer owning a pointer. For
example, consider:

struct B {};

struct A
{
public:
...
void add(B*);
...
private:
std::vector<B*> data_;
};

Here, A holds a vector of (heap-based) pointers to B, and has a
function to add a dynamically allocated pointer to the internal vector.
A first try at implementing this might be:

void
A::add(B* b)
{
data_.push_back(b); // Not good!
}

The problem with this implementation is that vector::push_back may
throw an exception. If it does, then b is leaked! The careful
programmer will make sure that add() assumes ownership of b no matter
what. auto_ptr can be used to easily implement this:

void
A::add(B* b)
{
std::auto_ptr<B> ap(b);
data_.push_back(b);
ap.release();
}

First add() assumes ownership of b by putting it into a local auto_ptr.
This auto_ptr constructor will not throw. Then the pointer is
push_back'd into the vector. If this operation throws, then b will be
deleted by the auto_ptr. If the push_back succeeds, then ownership of
b is transferred from the local auto_ptr, to A with the ap.release()
statement. Now A's copy constructor, assignment and destructor are
responsible for managing b's lifetime.

This enables idioms such as:

a.add(new B);

If A::add() did not assume ownership of its pointer even under
exceptional conditions, then there would be no way for client code to
recover in the above example.

It is true that shared_ptr could have done the job here. But
shared_ptr is overkill for this application (actually so is auto_ptr).
An auto_ptr constructor and destructor is /much/ cheaper than the
equivalent shared_ptr operations.

--
Howard Hinnant
Metrowerks

re: shared_ptr vs std::auto_ptr

"SerGioGio" <sergiogiogio@yahoo.fr> wrote in message
news:be15mu$i0g$1@news-reader3.wanadoo.fr...[color=blue]
> Hello !
>
> When a ref. counted smart pointer (template) class is available (like
> boost::shared_ptr), is there any (semantic) reason to still use
> std::auto_ptr rather than this smart pointer ? Or should one use[/color]
shared_ptr[color=blue]
> for every cases ?
>
> Thanks in advance for your remarks !
>
> SerGioGio
>[/color]

If I had to upgrade software like this:

Fred *pfred = new Fred(...);
// use pfred here
delete pfred;

I would probably use std::auto_ptr. I don't use that style of programming
myself and so have little use for std::auto_ptr. I find the semantics of
this class so treacherous, particularly the part where the assignment
operation changes the objects on both sides (!), that I greatly prefer
boost::shared_ptr for general use.

--
Cycho{HHR}
http://home.rochester.rr.com/cyhome/

re: shared_ptr vs std::auto_ptr

Cy Edmunds wrote:
[...][color=blue]
> myself and so have little use for std::auto_ptr. I find the semantics of
> this class so treacherous, particularly the part where the assignment
> operation changes the objects on both sides (!), ....[/color]

Yeah. Ever heard of "Einstein-Podolsky-Rosen correlation"? Quantum
mechanics, you know.

regards,
alexander.