Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: Why is this program slow? / C++ versus C Performance
Message-ID: <70067@microsoft.UUCP>
Date: 16 Jan 91 19:54:18 GMT
References: <1991Jan12.040453.6887@mentor.com> <470@mole-end.UUCP>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Distribution: usa
Organization: Microsoft Corp., Redmond WA
Lines: 45

In article <470@mole-end.UUCP> mat@mole-end.UUCP (Mark A Terribile) writes:
|> The problem is that cfront isn't smart enough to construct the vector sum
|> directly in the target variable 'a' instead of creating an intermediary
|> temporary object.
|
|Well, I'm not so sure of that.  There is a guarantee that the temporary
|objects WILL be created so that the side effects of constructors will occur--
|EXCEPT in a very few circumstances involving a copy constructor used as the
|second constructor in an initialization.

Ack!  I disagree that any such guarantee exists -- I claim that contrar-wise
ARM goes out of its way to state that any and all such uses of temporaries is
implementation dependent, and that the compiler does indeed have latitude to 
generate or not generate temporaries as it so chooses.

The commentary  on Page 299 of ARM states:

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

This "fundamental rule" unfortunately, does nothing to clarify where
a compiler _ought_ to be generating a temporary, that it then might possibly
be "optimized away" using the above "fundamental rule."

One thing [about the only thing] you can be sure of is that if you 
initialize a reference with a temporary, the temporary exists for
the duration of the scope it is created in [but I can't find the
pertinent chapter and verse in ARM today]

For a really interesting and related issue, see the Dec. "Journal of
C Language Translation" regards the issue of whether [C] functions must
return values by copying.  Clearly, in C++ return-by-reference requires
that answers be returned without copying -- but, where is it stated that
non-return-by-reference functions must return their "value" by making
a copy of that value?

....Kind of makes me wonder how, if at all, a C++ programmer can certainly
force a copy [other than introducing a named variable to represent that
copy, and is even that guaranteed to work?] and how in general C++ 
programmers are suppose to control object identity -- when they're doing
OOP, that is.

???