seq@jpl-devvax.jpl.nasa.gov (Sequence Folks) (03/28/91)
In spite of a previous confidence in my understanding of the copy
constructor, and with the ARM by my side, the following has me
baffled:
1) The compiler complains when I try to create an object from the heap
using the default copy constructor.
class D {};
D d;
D* pd;
pd = new D(d);
2) The compiler complains when I try to create an object from the heap
using the default copy constructor of a derived class when there is no
default copy constructor for the base class.
class B {};
class D : public B {};
D d;
D* pd;
pd = new D(d);
3) But everything works great if the base class has an explicity
defined copy constructor!
class B {
public:
B() {}
B(B&) {}
};
class D : public B {};
D d;
D* pd;
pd = new D(d);
4) And considering case #1, how come the *following* works?!
class B {
public:
virtual B* copy() {return new B(*this);}
};
This is all done on Sun cfront 2.0. I would appreciate an explanation
(and, if possible, an ARM reference).steve@taumet.com (Stephen Clamage) (03/29/91)
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. | class D {}; | D d; | D* pd; | pd = new D(d); This is a compiler bug. The code should work, and does on other compilers I tried. -- Steve Clamage, TauMetric Corp, steve@taumet.com
lijewski@theory.tn.cornell.edu (Mike Lijewski) (03/29/91)
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. >| class D {}; >| D d; >| D* pd; >| pd = new D(d); > >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. Granted, it also isn't explicitly disallowed, but considering all the examples and commentary, what is one to think? 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. My reading is basically that if a situation calls for a copy constructor, the compiler will do the "right thing". Am I reading something into this that isn't there, or could this be something that was intentionally left vague and up to the compiler implementer? >-- > >Steve Clamage, TauMetric Corp, steve@taumet.com -- Mike Lijewski (H)607/272-0238 (W)607/254-8686 Cornell National Supercomputer Facility ARPA: mjlx@eagle.cnsf.cornell.edu BITNET: mjlx@cornellf.bitnet SMAIL: 25 Renwick Heights Road, Ithaca, NY 14850
steve@taumet.com (Stephen Clamage) (03/31/91)
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
robert@kohlrabi.tcs.com (Robert Blumen) (04/02/91)
In article <645@taumet.com>, steve@taumet.com (Stephen Clamage) writes: |> 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. I understand that this is recognized as a bug in cfront 2.0 that will be corrected in 2.1 ----------------------------------------------------------------------------- Robert Blumen | rblumen@tcs.com Senior Software Engineer | 2121 Allston Way, Berkeley, CA 94704 Teknekron Communications Systems, Inc. | (415) 649-3759