rfg@NCD.COM (Ron Guilmette) (08/16/90)
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.