Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!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: <70222@microsoft.UUCP>
Date: 25 Jan 91 19:10:11 GMT
References: <1991Jan12.040453.6887@mentor.com| <470@mole-end.UUCP> <70067@microsoft.UUCP> <471@mole-end.UUCP>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Distribution: usa
Organization: Microsoft Corp., Redmond WA
Lines: 60

In article <471@mole-end.UUCP| mat@mole-end.UUCP (Mark A Terribile) writes:
|In article <70067@microsoft.UUCP>, jimad@microsoft.UUCP (Jim ADCOCK) writes:
|> |...  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 circum-
|> |tances involving a copy constructor ... the second ... 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, ...
|
|If you go back to the original problem, you'll see that the `temporaries'
|in questions were not compiler-generated, but were written by the programmer.
|(Perhaps I should have written `intermediate' instead of `temporary'?)  And
|there is a place where the compiler states that an EXCPLICITLY WRITTEN
|temporary/intermediate may, in effect, be eliminated:
|
|		X f(  .  .  .  )
|		{
|			. . .
|			return X( xarg1, xarg2 );
|		}
|
|Here the compiler, instead of creating a local X to evaluate the value
|builder, and then using it to initialize the returned value, may use the
|constructor value builder directly to initialize the returned value.

Agreed.  A named local variable is not a temporary.  Temporaries are
unnamed objects.  See ARM page 22:

"A NAMED LOCAL OBJECT may not be destroyed before the end of its block nor
 may a local named object of a class with a constructor or a destructor 
 with side effects be eliminated even if it appears to be unused."

[emphasis mine]

Contrarwise, whether an UNNAMED TEMPORARY is actually created, when 
either "explicitly" or "implicitly" called for by a programmer is 
strictly implementation dependent.  UNNAMED TEMPORARIES can be 
"optimized away" even if their constructors or destructors have side
effects.

The basic rule is that if you want to ensure that a copy is being made, 
you must explicitly give that copy a name.  This has some interesting
consequences.  Consider what the following function does:

Foo do_I_make_a_copy(Foo* foo) { return *foo; }

???


Interestingly, if a temporary is given a name by assigning a reference to
it, then the rules change and it essentially becomes a named object,
and is guaranteed to stay alive for the scope of the reference.  So,
it appears to be the named'ness of an object that is the 
determining factor in whether a compiler can optimize it away
[and therefor its constructor/destructor side effects]

Another unsolved question:  Can a compiler optimize-away a named object
that *doesn't* have a constructor nor destructor with side effects?  This
is still an interesting question in dealing with object identity.