🚀 go-pugleaf

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