🚀 go-pugleaf

In article <8904042239.AA07890@yahi.stanford.edu> tiemann@lurch.stanford.edu writes:
>Well, it all depends on the compiler you are using.  I know that at
>least AT&T cfront and GNU C++ are smarter than this.  What happens in
>these compilers is that the caller passes the address of the place
>where the new temporary should be initialized.  Depending on the way
>it is initialized, there may be no overhead visible from the call to
>operator+ at all:
>
>M operator+(M x, M y)
>{
>  return M (x.value () + y.value ());
>}
>
>In general, if the compiler can get away with generating an invisible
>temporary, it can do quite clever things.
>

Are you saying the compiler recognizes the fact that there's an M being
constructed in the return statement, and uses an already allocated temporary
instead of making a new one on the stack?  That's some compiler.  What
would really be nice is to have some way of using an existing object as
the result.  Of course, you can have  Madd(M &x, M &y, M &result), but then
you can't use operator overloading :-(.
I disagree that this is a case in which one should leave the efficiency
questions to the compiler.  In general one can assume, as Stroustrup
does (p. 178), that a situation like this is going to require putting the
object on the stack.  There are cases where this is simply too expensive;
I guess there is no option then but to do something like Madd(M &x, M &y,
M &result) and lose operator overloading.
Stroustrup points out in the same paragraph, if I had bothered to look
before, that what I described previously (returning a reference to a static
object) is not a good idea.

Bob Hearn
hearn@claris.com