optimization bug? in initialization of class variable

optimization bug? in initialization of class variable

[Andrew J. Malton]

Is this a bug or a very wierd valid interpretation of the standard?

Let T be a nonunion class type.

In the case of a declaration
	T v = e;
if e is not suitable for copy initialization, then the declaration means
	T v (T(e));
where the T(e) denotes a temporary created with suitable conversion 
construction [8.5 14].  So this should invoke a conversion followed by a 
copy.   Both constructors have to be accessible [12.2 1].  Creation of 
the temporary T(e) may be `avoided' [12.2 2 example] but semantic 
restrictions (acessibility) must still be satisfied.

In the attached example, GCC (2.95, also 3.0) checks accessibility of 
the constructors (verify by uncommenting the "private:"), but avoids 
creating the temporary, even though its constructor has a side effect.  
The program outputs 0.  I am surprised.  Is the theory that 
accessibility is a "semantic restriction" but the side effect is merely 
"semantics"?  Or is this a bug plain and simple?

-- cut here --

#include <iostream>

class C
{
     int x;
public:
     C (const int n) : x(n) { }
//private:
     C (const C& c) : x(c.x) { ++ copied; }
public:
     static int copied;
};

int C::copied = 0;

int main ()
{
     C c = 5;
     std::cout << C::copied << std::endl;
}



--
Dr. Andrew Malton, Associate Professor
Department of Computer Science
University of Waterloo
Waterloo, Canada N2L 3G1

http://www.cs.uwaterloo.ca/~ajmalton
tel: +1 519 888 4567 x 5144
fax: +1 519 885 1208

Re: optimization bug? in initialization of class variable

[Nathan Sidwell]

"Andrew J. Malton" wrote:
> 
> Is this a bug or a very wierd valid interpretation of the standard?
neither.


> where the T(e) denotes a temporary created with suitable conversion
> construction [8.5 14].  So this should invoke a conversion followed by a
> copy.   Both constructors have to be accessible [12.2 1].  Creation of
> the temporary T(e) may be `avoided' [12.2 2 example] but semantic
> restrictions (acessibility) must still be satisfied.
read [12.8]/15 which says some of the cases where a temporary can be
elided 'even if the class constructor or destructor have sideeffects'

This is one such case.

nathan
-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
           The voices in my head told me to say this
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk

Re: optimization bug? in initialization of class variable

[Joe Buck]

> In the attached example, GCC (2.95, also 3.0) checks accessibility of 
> the constructors (verify by uncommenting the "private:"), but avoids 
> creating the temporary, even though its constructor has a side effect.  
> The program outputs 0.  I am surprised.  Is the theory that 
> accessibility is a "semantic restriction" but the side effect is merely 
> "semantics"?  Or is this a bug plain and simple?

The standard says that under certain circumstances copies can be optimized
away even if the copy constructor has or might have a side effect.
Roughly speaking, the compiler is allowed to assume that the only reason
for a copy constructor is to make a copy, so if the compiler can avoid
making a copy it is entitled to do so.