🚀 go-pugleaf

Eugene Lazutkin wrote:
> > And the current wording of the draft allows such optimisations --
> > effectively arbitrary copy constructor invocations can be eliminated if
> > either the copy or the original is never used again (as in this example).
> 
> This is exactly the kind of optimization that one would be expecting but it cannot
> possibly work, at least not with the non-inline copy constructors:
> 
>         class   Complex
>         {
>                 Complex( const Complex& );
>         };
> 
>         int     stupid_global = 0;
>         Complex::Complex( const Complex& c ) : re( c.re ), im( c.im )
>         {
>                 stupid_global++;
>         }
> 
> compiler has no way to know that copy constructor has a non-local side effect.

	Completely irrelevent. The compiler is permitted to elide
the copy constructor anyhow. If this changes the observable behaviour
of you program it's your own fault that your code is not deterministic.
If you put a --stupid_global in the destructor, you can assume
after you're done it will be zero. But given a copy operation you 
can't assume it will be incremented by 1: it might be 2 or 0.
(0 is obviously not possible if the two variables are both used).

-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 web: http://www.maxtal.com.au/~skaller/
AUSTRALIA                      email: skaller@maxtal.com.au
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]