Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!csc.ti.com!ti-csl!tilde.csc.ti.com!osage.csc.ti.com!bmk
From: bmk@osage.csc.ti.com (Brian M Kennedy)
Newsgroups: comp.lang.c++
Subject: Re: Correction to Re: Default constructor, unexpected call
Message-ID: <1990Aug14.190925.19166@csc.ti.com>
Date: 14 Aug 90 19:09:25 GMT
Sender: usenet@csc.ti.com (USENET News System)
Organization: TI Computer Science Center, Dallas
Lines: 112

In article <615@dlogics.COM>, dsa@dlogics.COM (David Angulo) writes:
=>
=>In article <643@atcmpe.atcmp.nl>, leo@atcmp.nl (Leo  Willems) writes:
=>=> My question is simple: why does the following program generate a 
=>=> call to the default constructor from class A for variable 'copd'?
=>=> 
=>=> (If this is not a bug in 2.1 (2.0 as well) try switching the
=>=>  declarations of a and b in class C; then A::A() is not called: if the 
=>=> previous one is NOT a bug then this one is!)
=>=> 
=>=> #include <stdio.h>
=>=> 
=>=> class A{
=>=> public:
=>=> 	A() { ida = 0; puts("default constructor A()"); }
=>=> 	A(int i) {ida = i; puts("constructor A(int)"); }
=>=> private:
=>=> 	int ida;
=>=> };
=>=> 
=>=> class B{
=>=> public:
=>=> 	B() { idb = 0; puts("default constructor B()"); }
=>=> 	B(B& b) { idb = b.idb; puts("copy constructor B(B&)"); }
=>=> private:
=>=> 	int idb;
=>=> };
=>=> 
=>=> class C{
=>=> public:
=>=> 	C(){ puts("default constructor C()");}
=>=> protected:
=>=> 	A a;	//switch these: bug(?) gone 
=>=> 	B b;    // if not a bug: A::A() gone!!!!
=>=> };
=>=> 
=>=> main()
=>=> {
=>=> 	puts(" first a 'default' constructor:");
=>=> 	C defd;
=>=> 
=>=> 	puts("\n now the copy constructor: ");
=>=> 
=>=> 	C copd(defd);	//suspicious A::A() class here
=>               ^^^^
=>       Well, I don't know how this compiled because you don't have
=>       anything other than a default constructor for class C.  This
=>       shouldn't have compiled!
=>
=>=> }
=>=> 

In response to David, this should compile.  A copy constructor is implicitly
defined for every class unless a copy constructor is explicitly defined.
In this case, the following declaration in class C is implicit:

      C (C&);

(Note, it is not C (const C&) because C has a member B which has a copy 
constructor that does not accept a const argument. E&S p295)


In response to Leo's question, which I will rephrase "Why does the implicit
copy constructor generated for class C call the default constructor for class
A?  Is this a bug?":

There are many statements in E&S which somewhat imply how an implicit copy
constructor is implemented -- however, it is never spelled out.  I believe
Leo is assuming (a perfectly reasonable assumption) that it is implemented as:

      C (C& i) :a(i.a), b(i.b) {}

where b(i.b) calls the user-defined copy constructor, and a(i.a) calls the
implicit constructor

      A (A& i) :ida(i.ida) {}

A look at the cfront 2.00.01 generated C shows that the implicit copy 
constructor is defined using the implicit memberwise assignment (or, at
least, achieves a similar result):

      C (C& i) :a(), b(i.b) {<perform "bitwise" copy of i.a to a>}


Is it a compiler bug?  Only if the C++ language requires compilers to 
define copy constructors a certain way.  I do not believe E&S does so.
It does define exactly how copy constructors should be DECLARED and 
when they should be DEFINED, but it only hints at how it should be
DEFINED.  In fact, E&S (p295) hints that a compiler could do "bitwise" 
copying in the implicit copy constructors.  Perhaps the ANSI spec should
be more clear about this.


So, as with any language or architecture spec, if the language definition
does not define something, you should not assume that it is one way -- 
Murphy's law will see to it that you get burned ;-)

In all but the simplest of the classes that I write, I always define both
a default constructor and a copy constructor.  Then I always know how it 
is defined (besides, it is next to trivial to write).

Hope that helps.

Disclaimer:  I have made educated guesses -- only the ATT'ers can say for
             sure what cfront is trying to do here and whether or not it
             is a bug (i.e. unintended behavior).

---------------------------------
Brian M. Kennedy <bmk@csc.ti.com>
Computer Systems Laboratory
Computer Science Center
Texas Instruments Incorporated