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

Eugene Lazutkin <eugene@int.com> wrote:
>To me, the step (2) can be eliminated by certain amendment to the semantics 
>of the language while (3) seems to be inherent. I wonder though if 
>something could be done about it within the bounds of the current 
>standard...

See ARM section 12.1c. "The fundamental rule is that the introduction of
a temporary object and the calls of its constructor/destructor pair may be
eliminated if the only way the user can detect its elimination or
introduction is by observing side effects generated by the constructor
or destructor call."

In your case, all temporaries can be eliminated.

----
Nicolas Chapados                          Member of Scientific Staff
chapados@bnr.ca                           Bell-Northern Research Ltd.


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

In article <01BAE696.8C249300@dino.int.com> Eugene Lazutkin <eugene@int.com> writes:

> 	Complex c( a+b );

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

> 1) Temporary Complex object constructed in 'operator +'
> 2) Return value of 'operator +' copy-constructed from (1)
> 3) 'c', copy-constructed from (2)

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

But it can be optimized -- essentially the implementation is permitted
to assume that the copy constructor does not have any important
side effects.  Moreover, lots of implementations perform this kind
of optimization.
-- 
				--Andrew Koenig
				  ark@research.att.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. ]

In article <01BAE696.8C249300@dino.int.com>, Eugene Lazutkin
<eugene@int.com> wrote:

>> ----------
>> 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?
>> 
>> 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, 
>> namely:
>> 
>> 1) Temporary Complex object constructed in 'operator +'
>> 2) Return value of 'operator +' copy-constructed from (1)
>> 3) 'c', copy-constructed from (2)
>> 

For simplicity, let's write this as :

Complex callee() {
    return Complex(0,0);
    }

void caller() {
    Complex a = callee(); // which is basically the same as a(callee())
    }

There are two points of interest :
1) the "caller" function
2) the "callee" function

Let's see what the compilers knows at each point :

1) the compiler knows it's going to call a function the returns an object.
So it might make some space on the stack for the returned object and put a
pointer to this space somewhere in the argument list to the "callee()"
function.

2) the compiler know that this function is going to return an object, so
it expects to find a pointer to place the newly created in. it indeed
creates a new object but it directly creates it in the "callee()" stack
space.

So now the, your example is actually doing only one step :

operator+ create the newly created "a+b" object directly in c.

-- 
-- Etay Bogner,
-- Etay_Bogner@mail.stil.scitex.com,
-- Scitex Corp.
-- Israel.
---
[ 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. ]