[comp.lang.c++] copy constructor semantics

wells@thegang.uucp (David Wells) (06/04/91)

can someone please clarify an issue i have concerning copy constructor semantics?

in section 12.6.1 of Ellis and Stroustrup's ARM, (on the bottom of page 286) it
is stated that initializing a class object with an explicit = results in a
copy constructor being invoked.

a little later on page 287, further clarification is offered, to the effect that
even if a temporary object is optimized away, "the semantics are not affected."

in other words, if the copy constructor of a class is protected or private, 
i shouldn't be able to publicly initialize the class with an explicit =. 

the book offers an example which is equivalent to the following:

class A
{
	public:
		A();
	protected:
		A(A&);
};

void
main
{

	A test;               // this is legal
	A test1 = test;       // this is illegal
	A test2 = A();	      // this should be illegal too, but isn't
}


i tested this using Borland C++, Glockenspiel C++, and Zortech C++. 

all three compilers disallowed the above initialization of test1
but allowed the initialization of test2, which doesn't seem to be 
consistent with my interpretation of the ARM. 

does anyone know if the ARM's treatment of copy constructors has been revised?
 
please send replies via e-mail to:

		 uupsi!thegang!wells

thanks for your help

mike@taumet.com (Michael S. Ball) (06/04/91)

In article <1991Jun03.220604.18506@thegang.uucp> wells@thegang.uucp (David Wells) writes:
>can someone please clarify an issue i have concerning copy constructor semantics?
>
>in section 12.6.1 of Ellis and Stroustrup's ARM, (on the bottom of page 286) it
>is stated that initializing a class object with an explicit = results in a
>copy constructor being invoked.
:
>does anyone know if the ARM's treatment of copy constructors has been revised?

The ARM's treatment was itself a late revision and has not yet been inserted
into most compilers.  This was a grey area in the language, and most
compiler vendors elected to follow cfront rather than break new ground.
-- 
Michael S. Ball			mike@taumet.com
TauMetric Corporation		(619)697-7607