shared_ptr vs std::auto_ptr

Discussion in 'C++' started by SerGioGio, Jul 3, 2003.

  1. SerGioGio

    SerGioGio Guest

    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
     
    SerGioGio, Jul 3, 2003
    #1
    1. Advertising

  2. In article <be15mu$i0g$>, SerGioGio
    <> 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
     
    Howard Hinnant, Jul 3, 2003
    #2
    1. Advertising

  3. SerGioGio

    Cy Edmunds Guest

    "SerGioGio" <> wrote in message
    news:be15mu$i0g$...
    > 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/
     
    Cy Edmunds, Jul 3, 2003
    #3
  4. 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.
     
    Alexander Terekhov, Jul 3, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ctick
    Replies:
    4
    Views:
    9,006
    Richard Herring
    Jun 22, 2004
  2. Siemel Naran

    auto_ptr<Derived> to auto_ptr<Base>

    Siemel Naran, Jan 10, 2005, in forum: C++
    Replies:
    2
    Views:
    1,566
    Dave Rahardja
    Jan 11, 2005
  3. Markus Dehmann

    auto_ptr vs shared_ptr

    Markus Dehmann, Jun 1, 2005, in forum: C++
    Replies:
    3
    Views:
    10,501
    msalters
    Jun 2, 2005
  4. Colin Caughie
    Replies:
    1
    Views:
    738
    Shooting
    Aug 29, 2006
  5. Jarek Blakarz

    passing auto_ptr as shared_ptr

    Jarek Blakarz, Dec 22, 2012, in forum: C++
    Replies:
    2
    Views:
    466
    Jarek Blakarz
    Dec 22, 2012
Loading...

Share This Page