copy constructor of std::auto_ptr<>

[dragoncoder]

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

 

[mlimber]

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

 

[Salt_Peter]

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.

 

[Alf P. Steinbach]

* 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.

 

[Pete Becker]

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.

 

[Nindi]

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()) //
}

 

[Salt_Peter]

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.

 

[Nindi]

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.

 

[Noah Roberts]

* Salt_Peter:

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

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

 

[Alf P. Steinbach]

* Noah Roberts:

Uh oh..not this one again

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).

 

[Pete Becker]

Uh oh..not this one again

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)