Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > shared_ptr vs std::auto_ptr

Reply
Thread Tools

shared_ptr vs std::auto_ptr

 
 
SerGioGio
Guest
Posts: n/a
 
      07-03-2003
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


 
Reply With Quote
 
 
 
 
Howard Hinnant
Guest
Posts: n/a
 
      07-03-2003
In article <be15mu$i0g$(E-Mail Removed)>, SerGioGio
<(E-Mail Removed)> 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:ush_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
 
Reply With Quote
 
 
 
 
Cy Edmunds
Guest
Posts: n/a
 
      07-03-2003
"SerGioGio" <(E-Mail Removed)> wrote in message
news:be15mu$i0g$(E-Mail Removed)...
> 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
>


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/


 
Reply With Quote
 
Alexander Terekhov
Guest
Posts: n/a
 
      07-03-2003

Cy Edmunds wrote:
[...]
> 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 (!), ....


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

regards,
alexander.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
#include <boost/shared_ptr.hpp> or #include "boost/shared_ptr.hpp"? Colin Caughie C++ 1 08-29-2006 02:19 PM
about shared_ptr Ernst Murnleitner C++ 4 01-12-2004 04:14 PM
boost::shared_ptr and operator->() Derek C++ 2 12-08-2003 05:13 PM
boost::shared_ptr inside stl::list James Mastro C++ 1 11-13-2003 01:59 AM
error with boost::shared_ptr<T> with incomplete T, VC7.1 ? Philippe Guglielmetti C++ 4 10-09-2003 05:30 PM



Advertisments