Compilers often perform Named Return Value Optimization (NRVO) in such cases, but it is not guaranteed.
> Note also that C doesn't have return-value-optimization, hence all your struct-returning functions will cause a call to memcpy (won't happen when compiled in C++ mode of course).
In the context of the C++ programming language, return value optimization (RVO) is a compiler optimization that involves eliminating the temporary object created to hold a function's return value. RVO is allowed to change the observable behaviour of the resulting program by the C++ standard.
Named RVO GCC performs NRVO by default, but it can be disabled using the -fno-elide-constructors + compiler option. In contrast, MSVC disables NRVO by default, but it can be enabled using /O2 optimization+.
Use exclusively the first method:
Foo f()
{
Foo result;
mangle(result);
return result;
}
This will already allow the use of the move constructor, if one is available. In fact, a local variable can bind to an rvalue reference in a return
statement precisely when copy elision is allowed.
Your second version actively prohibits copy elision. The first version is universally better.
All return values are either already moved
or optimized out, so there is no need to explicitly move with return values.
Compilers are allowed to automatically move the return value (to optimize out the copy), and even optimize out the move!
Section 12.8 of n3337 standard draft (C++11):
When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the copy/move constructor and/or destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy/move operation as simply two different ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization.This elision of copy/move operations, called copy elision, is permitted in the following circumstances (which may be combined to eliminate multiple copies):
[...]
Example:
class Thing { public: Thing(); ~Thing(); Thing(const Thing&); }; Thing f() { Thing t; return t; } Thing t2 = f();
Here the criteria for elision can be combined to eliminate two calls to the copy constructor of class
Thing
: the copying of the local automatic objectt
into the temporary object for the return value of functionf()
and the copying of that temporary object into objectt2
. Effectively, the construction of the local objectt
can be viewed as directly initializing the global objectt2
, and that object’s destruction will occur at program exit. Adding a move constructor toThing
has the same effect, but it is the move construction from the temporary object tot2
that is elided. — end example ]When the criteria for elision of a copy operation are met or would be met save for the fact that the source object is a function parameter, and the object to be copied is designated by an lvalue, overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue. If overload resolution fails, or if the type of the first parameter of the selected constructor is not an rvalue reference to the object’s type (possibly cv-qualified), overload resolution is performed again, considering the object as an lvalue.
It's quite simple.
return buffer;
If you do this, then either NRVO will happen or it won't. If it doesn't happen then buffer
will be moved from.
return std::move( buffer );
If you do this, then NVRO will not happen, and buffer
will be moved from.
So there is nothing to gain by using std::move
here, and much to lose.
There is one exception* to the above rule:
Buffer read(Buffer&& buffer) { //... return std::move( buffer ); }
If
buffer
is an rvalue reference, then you should usestd::move
. This is because references are not eligible for NRVO, so withoutstd::move
it would result in a copy from an lvalue.This is just an instance of the rule "always
move
rvalue references andforward
universal references", which takes precedence over the rule "nevermove
a return value".
* As of C++20 this exception can be forgotten. Rvalue references in return
statements are implicitly moved from, now.
If you're returning a local variable, don't use move()
. This will allow the compiler to use NRVO, and failing that, the compiler will still be allowed to perform a move (local variables become R-values within a return
statement). Using move()
in that context would simply inhibit NRVO and force the compiler to use a move (or a copy if move is unavailable). If you're returning something other than a local variable, NRVO isn't an option anyway and you should use move()
if (and only if) you intend to pilfer the object.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With