🚀 go-pugleaf

Eugene Lazutkin <eugene@int.com> writes:

>----------
>From: 	Max Motovilov[SMTP:max@int.com]
>Sent: 	Friday, January 19, 1996 4:01 PM
>To: 	'Eugene Lazutkin'
>Subject: 	(for comp.std.c++)  Inherent C++ problem?

>Looks like Subj to me, but maybe I misunderstand something or overlooking a 
>simple workaround...

>Here is the example:

>	struct	Complex
>	{
>		double re, im;

>		Complex( double r, double i ) : re( r ), im( i ) {}
>		Complex( const Complex& c ) : re( c.re ), im( c.im ) {}
>	};

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

>It is all right by now. Consider the following use then:

>	Complex a( 1, 0 ), b( 0, 1 );
>	Complex c( a+b );

>In the last line 3 objects of type Complex are constructed instead of 1, ...

>This is inefficient to the last extreme, moreover it cannot even be 
>optimized out since any copy-constructor can theoretically have non-local 
>side effects....

That is not true. Under some circumstances extra temporary objects
may be optimized away, even when the copy constructor has global
side effects. (That means that correctness of your program should
not depend on how many temporaries get generated.)

In the example, the result returned from a+b can be constructed
directly in the parameter used to build 'c'. (I'm assuming this
example is deliberately simplified; you would not really need to 
write a copy construtor for this class. But lets speak to the more
general point where copying is not trivial.)

Here is part of the relevent section in the draft standard:

12.2 Temporary objects
While evaluating an expression, it might be necessary or convenient
for an implementation to generate temporary objects to hold values
resulting from the evaluation of the expression's subexpressions.
During this evaluation, precisely when such temporaries are
introduced is unspecified.
--
Steve Clamage, stephen.clamage@eng.sun.com

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