By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,411 Members | 999 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,411 IT Pros & Developers. It's quick & easy.

copy constructor of std::auto_ptr<>

P: n/a
Hi all,

I am trying to understanding std::auto_ptr<Tclass 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

Nov 13 '06 #1
Share this Question
Share on Google+
10 Replies


P: n/a
dragoncoder wrote:
Hi all,

I am trying to understanding std::auto_ptr<Tclass 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

Nov 13 '06 #2

P: n/a

dragoncoder wrote:
Hi all,

I am trying to understanding std::auto_ptr<Tclass 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.

Nov 13 '06 #3

P: n/a
* 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?
Nov 13 '06 #4

P: n/a
dragoncoder wrote:
>
I am trying to understanding std::auto_ptr<Tclass 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.
Nov 13 '06 #5

P: n/a

dragoncoder wrote:
Hi all,

I am trying to understanding std::auto_ptr<Tclass 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()) //
}

Nov 13 '06 #6

P: n/a

dragoncoder wrote:
Hi all,

I am trying to understanding std::auto_ptr<Tclass 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.

Nov 13 '06 #7

P: n/a

Salt_Peter wrote:
dragoncoder wrote:
Hi all,

I am trying to understanding std::auto_ptr<Tclass 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.

Nov 14 '06 #8

P: n/a

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.

Nov 14 '06 #9

P: n/a
* 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?
Nov 14 '06 #10

P: n/a
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)
Nov 14 '06 #11

This discussion thread is closed

Replies have been disabled for this discussion.