In article <1990Aug14.190925.19166@csc.ti.com> bmk@osage.csc.ti.com (Brian M Kennedy) writes:
<...
<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.

No.  The ANSI standard should *DEFINITELY* be more clear about this!

Note that the same lack of specificity exists also for the definitions
of implicitly supplied (i.e. compiler generated) default constructors
and assignment operators.

--

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.