copy constructor of std::auto_ptr<>

Discussion in 'C++' started by dragoncoder, Nov 13, 2006.

  1. dragoncoder

    dragoncoder Guest

    Hi all,

    I am trying to understanding std::auto_ptr<T> class implementation from
    "The C++ standard library" by Nicolai Josuttis. He gives a sample
    implementation of auto_ptr class template in section 4.2. The copy
    constructor is defined as:

    auto_ptr (auto_ptr& rhs) throw()
    : ap (rhs. release()) {
    }

    I was wondering, is there not a leak here ? I mean before taking
    ownership of the memory pointed to by rhs, shouldn't the memory pointed
    to by ap be relased (freed) ? I am expecting the copy constructor to be
    this way:

    auto_ptr(auto_ptr& rhs) throw() {
    delete ap; // Isn't this required ?
    ap = rhs.release();
    }

    If the delete ap is removed from the definition, I think the memory
    which is already being pointed to by ap (before the copy constructor is
    called) will leak. Please comment.

    Thanks in advance.

    /P
     
    dragoncoder, Nov 13, 2006
    #1
    1. Advertising

  2. dragoncoder

    mlimber Guest

    dragoncoder wrote:
    > Hi all,
    >
    > I am trying to understanding std::auto_ptr<T> class implementation from
    > "The C++ standard library" by Nicolai Josuttis. He gives a sample
    > implementation of auto_ptr class template in section 4.2. The copy
    > constructor is defined as:
    >
    > auto_ptr (auto_ptr& rhs) throw()
    > : ap (rhs. release()) {
    > }
    >
    > I was wondering, is there not a leak here ? I mean before taking
    > ownership of the memory pointed to by rhs, shouldn't the memory pointed
    > to by ap be relased (freed) ? I am expecting the copy constructor to be
    > this way:
    >
    > auto_ptr(auto_ptr& rhs) throw() {
    > delete ap; // Isn't this required ?
    > ap = rhs.release();
    > }
    >
    > If the delete ap is removed from the definition, I think the memory
    > which is already being pointed to by ap (before the copy constructor is
    > called) will leak. Please comment.


    You're confusing the assignment operator with the copy constructor. The
    latter is, by definition, only invoked for an object that has not yet
    been created and therefore does not have anything to delete.

    Cheers! --M
     
    mlimber, Nov 13, 2006
    #2
    1. Advertising

  3. dragoncoder

    Salt_Peter Guest

    dragoncoder wrote:
    > Hi all,
    >
    > I am trying to understanding std::auto_ptr<T> class implementation from
    > "The C++ standard library" by Nicolai Josuttis. He gives a sample
    > implementation of auto_ptr class template in section 4.2. The copy
    > constructor is defined as:
    >
    > auto_ptr (auto_ptr& rhs) throw()
    > : ap (rhs. release()) {
    > }
    >
    > I was wondering, is there not a leak here ? I mean before taking
    > ownership of the memory pointed to by rhs, shouldn't the memory pointed
    > to by ap be relased (freed) ? I am expecting the copy constructor to be
    > this way:
    >
    > auto_ptr(auto_ptr& rhs) throw() {
    > delete ap; // Isn't this required ?


    No, its not required. ap is not set at this point.
    Copy ctors create new objects.
    Its the rhs.ap that has the object. therefore... release() ... to
    transfer ownership

    > ap = rhs.release();
    > }
    >
    > If the delete ap is removed from the definition, I think the memory
    > which is already being pointed to by ap (before the copy constructor is
    > called) will leak. Please comment.


    copy ctors aren't called, they are invoked.

    >
    > Thanks in advance.
    >
    > /P


    Thats a copy ctor.
    You are confusing construction and assignment (where auto_ptr *does*
    own an object).

    Now look at the assignment operator (which is really what you had in
    mind):

    template< typename T >
    auto_ptr& operator= (auto_ptr< T >& rhs) throw()
    {
    reset(rhs.release()); // release rhs.ap and (re)set this->ap with its
    value.
    return *this;
    }

    Which in effect transfers ownership.

    note:

    int n(5); // ctor
    n = 4; // asignment
    int m = n; // copy ctor - NOT an assignment !!!
    int x(n); // copy ctor
    m = x; // assignment

    assignments modify an existing object, all ctors, including copy ctors,
    create a *new* objects.
    The difference between a plain ctor and a copy ctor is how the members
    are getting their values.
    All ctors construct (one way or another).
    Assignments do not construct.

    Its futile to zap any member in a copy since its a brand new object.
    Sorry, i can't say it any other way.
     
    Salt_Peter, Nov 13, 2006
    #3
  4. * Salt_Peter:
    >
    > copy ctors aren't called, they are invoked.


    The C++ standard mostly uses the term "called". In a few places it uses
    the term "invoked". There's no inherent difference in meaning, but no
    matter whether "call" or "invoked" is used, there are several different
    possible meanings, and the one that applies depends on the context.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Nov 13, 2006
    #4
  5. dragoncoder

    Pete Becker Guest

    dragoncoder wrote:
    >
    > I am trying to understanding std::auto_ptr<T> class implementation from


    Bad idea. <g> auto_ptr is a dreadful hack. It relies on corner cases in
    the language definition, and it's tricky to implement.

    --

    -- Pete
    Roundhouse Consulting, Ltd. -- www.versatilecoding.com
    Author of "The Standard C++ Library Extensions: a Tutorial and
    Reference." For more information about this book, see
    www.petebecker.com/tr1book.
     
    Pete Becker, Nov 13, 2006
    #5
  6. dragoncoder

    Nindi Guest

    dragoncoder wrote:
    > Hi all,
    >
    > I am trying to understanding std::auto_ptr<T> class implementation from
    > "The C++ standard library" by Nicolai Josuttis. He gives a sample
    > implementation of auto_ptr class template in section 4.2. The copy
    > constructor is defined as:
    >
    > auto_ptr (auto_ptr& rhs) throw()
    > : ap (rhs. release()) {
    > }
    >
    > I was wondering, is there not a leak here ? I mean before taking
    > ownership of the memory pointed to by rhs, shouldn't the memory pointed
    > to by ap be relased (freed) ? I am expecting the copy constructor to be
    > this way:
    >
    > auto_ptr(auto_ptr& rhs) throw() {
    > delete ap; // Isn't this required ?
    > ap = rhs.release();
    > }
    >
    > If the delete ap is removed from the definition, I think the memory
    > which is already being pointed to by ap (before the copy constructor is
    > called) will leak. Please comment.
    >




    When this constructor is invoked there is no memory to be freed, the
    object was not alive before.

    But I think its wrong to call this constructor the copy constructor.
    I think the copy constructor and copy asignment of auto_ptr are
    private. This is why you cannot do

    std::vector<auto_ptr<T> > v;
    v.push_back( auto_ptr<T>(new T) );

    The copy constructor and copy asignment are supposed to have
    signatures ( at least I think)

    class T {
    ........
    T(const T& t);
    T& operator=(const T& t);
    ..........
    };

    For auto_ptr

    auto_ptr<T> (auto_ptr<T>& t);
    auto_ptr<T>& operator=(auto_ptr<T>& t);

    are public but

    auto_ptr<T> (const auto_ptr<T>& t);
    auto_ptr<T>& operator=(const auto_ptr<T>& t);

    are private.

    auto_ptr<T>& operator=(const auto_ptr<T>& t) should be defined as

    auto_ptr<T>& operator=(auto_ptr<T>& t){
    this->reset(t.release()) //
    }
     
    Nindi, Nov 13, 2006
    #6
  7. dragoncoder

    Salt_Peter Guest

    dragoncoder wrote:
    > Hi all,
    >
    > I am trying to understanding std::auto_ptr<T> class implementation from
    > "The C++ standard library" by Nicolai Josuttis. He gives a sample
    > implementation of auto_ptr class template in section 4.2. The copy
    > constructor is defined as:
    >
    > auto_ptr (auto_ptr& rhs) throw()
    > : ap (rhs. release()) {
    > }
    >
    > I was wondering, is there not a leak here ? I mean before taking
    > ownership of the memory pointed to by rhs, shouldn't the memory pointed
    > to by ap be relased (freed) ? I am expecting the copy constructor to be
    > this way:
    >
    > auto_ptr(auto_ptr& rhs) throw() {
    > delete ap; // Isn't this required ?
    > ap = rhs.release();
    > }
    >
    > If the delete ap is removed from the definition, I think the memory
    > which is already being pointed to by ap (before the copy constructor is
    > called) will leak. Please comment.
    >
    > Thanks in advance.
    >
    > /P


    As already mentioned:

    Don't waist your time with auto_ptr.
    Understand that it breaks the rules since the source is modified on
    copy and assignment.
     
    Salt_Peter, Nov 14, 2006
    #7
  8. dragoncoder

    Nindi Guest

    Salt_Peter wrote:
    > dragoncoder wrote:
    > > Hi all,
    > >
    > > I am trying to understanding std::auto_ptr<T> class implementation from
    > > "The C++ standard library" by Nicolai Josuttis. He gives a sample
    > > implementation of auto_ptr class template in section 4.2. The copy
    > > constructor is defined as:
    > >
    > > auto_ptr (auto_ptr& rhs) throw()
    > > : ap (rhs. release()) {
    > > }
    > >
    > > I was wondering, is there not a leak here ? I mean before taking
    > > ownership of the memory pointed to by rhs, shouldn't the memory pointed
    > > to by ap be relased (freed) ? I am expecting the copy constructor to be
    > > this way:
    > >
    > > auto_ptr(auto_ptr& rhs) throw() {
    > > delete ap; // Isn't this required ?
    > > ap = rhs.release();
    > > }
    > >
    > > If the delete ap is removed from the definition, I think the memory
    > > which is already being pointed to by ap (before the copy constructor is
    > > called) will leak. Please comment.
    > >
    > > Thanks in advance.
    > >
    > > /P

    >
    > As already mentioned:
    >
    > Don't waist your time with auto_ptr.
    > Understand that it breaks the rules since the source is modified on
    > copy and assignment.





    I am not sure why you say this, what rules is it breaking ? The source
    is only modified when passed as a non-const reference. The user knows
    the signature of this assignement and constructor, and these do not
    promise not to midify the source.
     
    Nindi, Nov 14, 2006
    #8
  9. dragoncoder

    Noah Roberts Guest

    Alf P. Steinbach wrote:
    > * Salt_Peter:
    > >
    > > copy ctors aren't called, they are invoked.

    >
    > The C++ standard mostly uses the term "called". In a few places it uses
    > the term "invoked". There's no inherent difference in meaning, but no
    > matter whether "call" or "invoked" is used, there are several different
    > possible meanings, and the one that applies depends on the context.


    Uh oh..not this one again :p

    Actually the future standard is going to have a very specific
    definition of invoke. See section 3 in TR1.
     
    Noah Roberts, Nov 14, 2006
    #9
  10. * Noah Roberts:
    > Alf P. Steinbach wrote:
    >> * Salt_Peter:
    >>> copy ctors aren't called, they are invoked.

    >> The C++ standard mostly uses the term "called". In a few places it uses
    >> the term "invoked". There's no inherent difference in meaning, but no
    >> matter whether "call" or "invoked" is used, there are several different
    >> possible meanings, and the one that applies depends on the context.

    >
    > Uh oh..not this one again :p


    Yes, it should be a FAQ.


    > Actually the future standard is going to have a very specific
    > definition of invoke. See section 3 in TR1.


    Sorry, that's incorrect. Presumably you're referring to TR1:ยง3.3.
    That's a technical helper definition for a very specific (contextual)
    meaning of invoke/call, namely to help define the functionality of
    functor objects, which is why INVOKE is spelled in uppercase. INVOKE in
    uppercase in that section of TR1 is not the same as invoke or call in
    lowercase in the standard, or for that matter, in TR1 (also TR1 uses the
    terms "call" and "invoke" interchangeably).

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Nov 14, 2006
    #10
  11. dragoncoder

    Pete Becker Guest

    Noah Roberts wrote:
    > Alf P. Steinbach wrote:
    >> * Salt_Peter:
    >>> copy ctors aren't called, they are invoked.

    >> The C++ standard mostly uses the term "called". In a few places it uses
    >> the term "invoked". There's no inherent difference in meaning, but no
    >> matter whether "call" or "invoked" is used, there are several different
    >> possible meanings, and the one that applies depends on the context.

    >
    > Uh oh..not this one again :p
    >
    > Actually the future standard is going to have a very specific
    > definition of invoke. See section 3 in TR1.
    >


    That's INVOKE, not invoke. C++ is case sensitive. INVOKE and INVOKE_R
    are used to describe the effects of a function call operator applied to
    any of the four callable types defined in TR1. They don't affect the
    meaning of the English word 'invoke'.

    --

    -- Pete
    Roundhouse Consulting, Ltd. (www.versatilecoding.com)
    Author of "The Standard C++ Library Extensions: a Tutorial and
    Reference." (www.petebecker.com/tr1book)
     
    Pete Becker, Nov 14, 2006
    #11
    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. Siemel Naran

    auto_ptr<Derived> to auto_ptr<Base>

    Siemel Naran, Jan 10, 2005, in forum: C++
    Replies:
    2
    Views:
    1,557
    Dave Rahardja
    Jan 11, 2005
  2. Replies:
    4
    Views:
    438
  3. dolphin
    Replies:
    2
    Views:
    317
  4. Sousuke
    Replies:
    9
    Views:
    1,153
    Bart van Ingen Schenau
    Mar 16, 2010
  5. XP
    Replies:
    4
    Views:
    1,226
Loading...

Share This Page