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_p tr& 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]

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_p tr& 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]

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_p tr& 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.relea se()); // 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.

--
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?

[Pete Becker]

dragoncoder wrote:

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

Bad idea. <gauto_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]

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_p tr& 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<aut o_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(cons t 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.releas e()) //
}

[Salt_Peter]

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_p tr& 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]

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_p tr& 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.

[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

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

[Alf P. Steinbach]

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