Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > copy constructor of std::auto_ptr<>

Reply
Thread Tools

copy constructor of std::auto_ptr<>

 
 
dragoncoder
Guest
Posts: n/a
 
      11-13-2006
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

 
Reply With Quote
 
 
 
 
mlimber
Guest
Posts: n/a
 
      11-13-2006
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

 
Reply With Quote
 
 
 
 
Salt_Peter
Guest
Posts: n/a
 
      11-13-2006

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.

 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      11-13-2006
* 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?
 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      11-13-2006
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.
 
Reply With Quote
 
Nindi
Guest
Posts: n/a
 
      11-13-2006

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

 
Reply With Quote
 
Salt_Peter
Guest
Posts: n/a
 
      11-14-2006

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.

 
Reply With Quote
 
Nindi
Guest
Posts: n/a
 
      11-14-2006

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.

 
Reply With Quote
 
Noah Roberts
Guest
Posts: n/a
 
      11-14-2006

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

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

 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      11-14-2006
* 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


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?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
template copy constructor vs normal copy constructor cinsk C++ 35 10-10-2010 11:14 PM
A constructor calling another constructor (default constructor)? Generic Usenet Account C++ 10 11-28-2007 04:12 AM
Calling base class constructor from derived class Copy constructor ali C++ 4 03-05-2007 09:15 AM
deep/shallow copy - constructor v Object.copy() VisionSet Java 8 04-29-2004 10:41 PM
Copy constructor hides default constructor Aire C++ 3 01-25-2004 05:47 PM



Advertisments