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. ]

----------
From:  Max Motovilov[SMTP:max@int.com]
Sent:  Monday, January 22, 1996 8:52 AM
To:  'Eugene Lazutkin'
Subject:  Re: Inherent C++ problem (for comp.std.c++)

> Well, a typical optimisation here would be to construct the temporary
> inside op+ directly into the return value slot. The construction of 'c'
> would likely pass the address of 'c' as the return value slot. Thus, with
> suitable inlining, it becomes very efficient.

> 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:

//****** Complex.h

 class Complex
 {
 ............
  Complex( const Complex& );
 ............
 };

//****** Complex.cpp

 int stupid_global = 0;

 Complex::Complex( const Complex& c ) : re( c.re ), im( c.im )
 {
  stupid_global++;
 }

Now, in the body of the method

 Complex operator + ( const Complex& a, const Complex& b )
 {
  return Complex( a.re+b.re, a.im+b.im );
 }

compiler has no way to know that copy constructor has a non-local side effect.
Otherwise the case is exactly like the one suitable for optimization, that is, source
object is never going to be used again. However the presence or absence of the
optimization results in a different program behavior.

As for the (2) to (3) transition by means of reserving the slot by the caller rather
than the callee, the same concern applies. Standard doesn't require the compiler
to behave one way or the other thus the improper dependance on the optional
optimization may take place in the program. Since there is apparently no way to
prohibit side effects in copy constructors (without compromizing certain consitency
in the language) and it is unwise to impose any requirements on the way compilers
implement object return by value it should probably be explicitly said in the standard
that in certain cases invokation of the copy constructor (that is, method call!) is
not guaranted by the implementation. It would be still bad for a consistent design,
but at least unambiguous....

If the current wording is already supposed to provide for it, I suggest it Re:made more
explicit in regard to this problem.

...Max...
---
[ 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. ]