Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!taumet!steve
From: steve@taumet.com (Stephen Clamage)
Newsgroups: comp.lang.c++
Subject: Re: The "new" Operator and the Copy Constructor
Message-ID: <645@taumet.com>
Date: 30 Mar 91 20:41:21 GMT
References: <1991Mar27.233549.1487@jpl-devvax.jpl.nasa.gov> <643@taumet.com> <1991Mar29.024933.21277@batcomputer.tn.cornell.edu>
Organization: Taumetric Corporation, San Diego
Lines: 34

lijewski@theory.tn.cornell.edu (Mike Lijewski) writes:

>In article <643@taumet.com> steve@taumet.com (Stephen Clamage) writes:
>>seq@jpl-devvax.jpl.nasa.gov (Sequence Folks) writes:
>>>1) The compiler complains when I try to create an object from the heap
>>>using the default copy constructor.
>>This is a compiler bug.  The code should work, and does on other 
>>compilers I tried.

>I don't quite agree with Stephen here.  Why should this work?
>Nowhere in the ARM can I find any indication that one is allowed to
>explicitly call a default copy constructor...

Section 12.1, page 264, near the bottom:
"A copy constructor is generated only if no copy constructor is declared."
This means that the compiler will provide a default version of the copy
constructor when needed.  How would it make sense to say it is ok to
call the copy constructor implicitly by using a value function parameter
of class type, but not ok to make explicit mention of the constructor?
The upshot is that every class has a copy constructor, period.

>There is even a sentence in the
>commentary which states that the default assignment operator needn't
>be generated unless it's address is taken, which is analogous to the
>default copy constructor situation.

An inline function may be called, yet there need be no address for that
function.  A compiler may choose to implement default versions of copy
constructors or assignment operators as inline functions.  When the
address is needed, the function must be emitted as a normal static function.

-- 

Steve Clamage, TauMetric Corp, steve@taumet.com