Is the assignment syntax for a variable definition an implicit copy
constructor call ?
(My belief is yes based on reading C++PL 3rd ed.; I have not read the
standard.)
If so and the variable definition is in a scope which does not have
access to the copy
constructor then the declaration is illegal and should not compile.
Suppose the compiler optimizes away the copy constructor call; one would
expect
that the optimization should not alter the legality.
I have found differing behavior between gcc version 2.96 20000731 (Red
Hat Linux 7.0),
CC: Sun WorkShop 6 update 1 C++ 5.2 Patch 109508-02 2001/03/04
and pgCC 3.2-3 Copyright 1989-2000, The Portland Group, Inc. All Rights
Reserved.

typedef float Scalar ;  // future template argument
class Quaternion {
public:
    Quaternion( Scalar r = 0, Scalar i = 0, Scalar j = 0, Scalar k = 0 )
;
private:
    Quaternion( Quaternion const & source ) ;
    Scalar t ;
    Scalar x ;
    Scalar y ;
    Scalar z ;
};

    Quaternion w = 42 ; // implicit conversion, possible temporary
    Quaternion x = Quaternion( 42 ) ; // explicit conversion, possible
temporary

These are errors in g++ and Sun CC, but not in pgCC.
Tracing indicates that all three compilers have eliminated the copy
constructor call.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3B27DBD0.D074AB66@osc.edu>, Scott Brozell <srb@osc.edu>
writes
>Is the assignment syntax for a variable definition an implicit copy
>constructor call ?
>(My belief is yes based on reading C++PL 3rd ed.; I have not read the
>standard.)
>If so and the variable definition is in a scope which does not have
>access to the copy
>constructor then the declaration is illegal and should not compile.

There are two situations:

In the first the initialiser is an instance of the same type as the
object being declared. In this case I believe the syntax is exactly
equivalent to the function notation form and a valid accessible copy
ctor must be used as the sole ctor. (However initialising an instance of
a base by slicing an instance of a derived adds complexity)

In the case of the intialiser implicitly calling a converting ctor (note
that copy ctors can be converting ctors:) then the converting ctor must
be both accessible and usable implicitly (i.e. must not be qualified as
explicit) and there must be an accessible copy ctor even though that can
be optimised away.

Compilers should be able to get the simple case right (and if they do
not, they should be named and shamed) However there is a problem if the
scope of the declaration allows the calling of a private copy ctor,
because when the compiler has optimised it away it is going to take a
very bright linker to notice that you never implemented the copy ctor.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Scott Brozell wrote:
>
> Is the assignment syntax for a variable definition an implicit copy
> constructor call ?

8.5.1p12: "The initialization that occurs in [various contexts] is
called _copy-initialization_ and is equivalent to the form

 T x = a;"

Copy-initialization is described in paragraph 14 of that section, which
basically says that the initializer is converted to a temporary of type
T. That process doesn't have to involve a converting constructor; it
might involve a type conversion operator instead. The temporary is then
copy constructed into 'x'. Per section 12.8p15, an implementation is
almost always allowed to avoid creating this temparary, and construct
directly into 'x'.

> If so and the variable definition is in a scope which does not have
> access to the copy
> constructor then the declaration is illegal and should not compile.
> Suppose the compiler optimizes away the copy constructor call; one would
> expect
> that the optimization should not alter the legality.

Correct - 12.2p1: "Even when the creation of a temporary object is
avoided (12.8), all the semantic restrictions must be respected as if
the temporary object was created. [_Example:_ even if the copy
constructor is not called, all the semantic restrictions, such as
accessibility (clause 11), shall be satisfied.]"

> I have found differing behavior between gcc version 2.96 20000731 (Red
> Hat Linux 7.0),
> CC: Sun WorkShop 6 update 1 C++ 5.2 Patch 109508-02 2001/03/04
> and pgCC 3.2-3 Copyright 1989-2000, The Portland Group, Inc. All Rights
> Reserved.
>
> typedef float Scalar ;  // future template argument
> class Quaternion {
> public:
>     Quaternion( Scalar r = 0, Scalar i = 0, Scalar j = 0, Scalar k = 0 )
> ;
> private:
>     Quaternion( Quaternion const & source ) ;
>     Scalar t ;
>     Scalar x ;
>     Scalar y ;
>     Scalar z ;
> };
>
>     Quaternion w = 42 ; // implicit conversion, possible temporary
>     Quaternion x = Quaternion( 42 ) ; // explicit conversion, possible
> temporary
>
> These are errors in g++ and Sun CC, but not in pgCC.
> Tracing indicates that all three compilers have eliminated the copy
> constructor call.

I believe that the pgCC behavior is incorrect.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]