Re: const reference to object returned by value
On 8/29/07 11:51 PM, in article 5jn0n6Fcs7dU1@mid.uni-berlin.de, "Ulrich
Eckhardt" <doomster@knuut.de> wrote:
rwf_20 wrote:
In the second line, I assumed that the temporary returned from the
function is then copied into 'obj'. Hence, the first line saves a
copy. My testing has proven this completely wrong. See the following
code and results. Is there anything in the standard that could
clarify this, or is this completely compiler-specific?
This is an example of the 'as if' rule in action. The compiler sees that
there is a temporary (the returnvalue) which is then used to initialise
another object. Since the copy of an object is the same as the object, it
can optimise out the actual copying and construct the object 'in place'. In
your case, the copy constructor has side effects that would make a
difference, but still it is supposed to not change the copying semantics
otherwise - hence an actual call can be optimized out.
testClass getResidentObject() const {
return m_object;
}
No, this optimization is precisely the kind of optimization that the "as-if"
rule does not permit - since it changes the observable behavior of the
program. The "as-if" rules permits only those optimizations that cannot be
detected (because the program runs just "as-if" the optimization had not
been applied). In this case, the program's failure to output "Copy" as
expected is easily detectable - and proves that the value returned by the
function called - was not in fact copied to its destination as expected.
Therefore the behavior of this C++ program does not adhere to the semantics
of its code - so, strictly by the terms of C++'s "as-if" rule, this
optimization would not be legal.
Nonetheless, this optimization (constructing the return value of a function
"in place") is legal - but only because the C++ Standard explicitly allows
it. A C++ compiler may optimize away the copying of a value returned by a
function call (and thereby cause the program's behavior to diverge from the
semantics of its code) - provided that certain conditions are met (see
?12.8/15).
The object outside and m_object must be distinct, a copy must be made here.
testClass getLocalTempObject() {
return testClass();
}
testClass getLocalObject() {
testClass t;
return t;
}
These two are basically equivalent, either a named, local object or a
temporary is returned. In either case, the 'original' object ceases to
exist, so the compiler can reuse it and construct it in the place of the
returnvalue. As you have seen yourself, some compilers are smart enough to
figure that out, others only for the first case.
The first example is a candidate for the Return Value Optimization (RVO),
and the second is a candidate for the Named Return Value Optimization (NRVO)
(and these are two most common names for this optimization). Note that in
order for the compiler to be able to apply the (N)RVO optimization to a
function, the function must - along each one of its potential execution
paths - return the same named (or unnamed) object.
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]