Re: C++0x: returning rvalue references, recycling temporaries
On 14 Sep., 05:09, Seungbeom Kim <musip...@bawi.org> wrote:
1. How is it more expensive by involving an extra move construction?
As far as I understand, move(x) above is just a shorthand for
static_cast<string&&>(x). Does the static_cast incur any (significant)
operation in the machine code level?
It is a little more expensive because a new temporary is created based
on an old one (by move construction) instead of recycling the old
temporary (by returning a reference to it).
2. Why do we need the move? It converts an lvalue reference to an rvalue
reference, but we are returning by (r)value anyway, and we can always
safely return a reference when the return type is not a reference and
that creates a copy of the referent; is this correct?
T foo(T& t) { return t; } // returns a *copy* of t
T foo(T&& t) { return t; } // what about this?
The return value is also copy constructed because 't' is a named
reference. Named references are treated as lvalue references. The
statement "return move(t);" forces move-construction of the return
value. A move() makes sense here because in the 2nd overload 't' is
guaranteed to be a temporary due to the more attractive 1st overload
(T&) for lvalues. So 't' won't be used anymore and can be destroyed.
What about not writing the explicit move: is it correct/desirable?
string operator+(string&& x, const string& y) { x += y; return x; }
Correct and safe. But this will copy-construct a new temporary based
on an old temporary. Since the old temporary isn't needed anymore a
move-construction of the new temporary is as safe but potentially
faster.
Cheers,
SG
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]