When should std::move be used on a function return value? [duplicate]

Question

This question already has answers here:

c++11 Return value optimization or move? [duplicate] (4 answers)

Closed 8 years ago.

In this case

struct Foo {};
Foo meh() {
 return std::move(Foo());
}

I'm pretty sure that the move is unnecessary, because the newly created Foo will be an xvalue.

But what in cases like these?

struct Foo {};
Foo meh() {
 Foo foo;
 //do something, but knowing that foo can safely be disposed of
 //but does the compiler necessarily know it?
 //we may have references/pointers to foo. how could the compiler know?
 return std::move(foo); //so here the move is needed, right?
}

There the move is needed, I suppose?

• R. Martinho Fernandes: When you are using Visual Studio.
• R. Martinho Fernandes: Just FYI in the second case, you cannot have any usable references/pointers to foo anymore when you return from the function.
• Bo Persson: What are you doing with the returned value? Foo f = meh(); worked with (N)RVO already in C++98.
• thang: I wonder if explicitly calling std::move will prevent NRVO...
• R. Martinho Fernandes: std::move is an identity operation. It never actually does anything. It's just a marker for rvalues. If the compiler has the move constructor of Foo on hand it can see if it has observable effects and decide upon that. If it has no observable effects, how can you tell the difference?

Answer 1

In the case of return std::move(foo); the move is superfluous because of 12.8/32:

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.

return foo; is a case of NRVO, so copy elision is permitted. foo is an lvalue. So the constructor selected for the "copy" from foo to the return value of meh is required to be the move constructor if one exists.

Adding move does have a potential effect, though: it prevents the move being elided, because return std::move(foo); is not eligible for NRVO.

As far as I know, 12.8/32 lays out the only conditions under which a copy from an lvalue can be replaced by a move. The compiler is not permitted in general to detect that an lvalue is unused after the copy (using DFA, say), and make the change on its own initiative. I'm assuming here that there's an observable difference between the two -- if the observable behavior is the same then the "as-if" rule applies.

So, to answer the question in the title, use std::move on a return value when you want it to be moved and it would not get moved anyway. That is:

• you want it to be moved, and
• it is an lvalue, and
• it is not eligible for copy elision, and
• it is not the name of a by-value function parameter.

Considering that this is quite fiddly and moves are usually cheap, you might like to say that in non-template code you can simplify this a bit. Use std::move when:

• you want it to be moved, and
• it is an lvalue, and
• you can't be bothered worrying about it.

By following the simplified rules you sacrifice some move elision. For types like std::vector that are cheap to move you'll probably never notice (and if you do notice you can optimize). For types like std::array that are expensive to move, or for templates where you have no idea whether moves are cheap or not, you're more likely to be bothered worrying about it.

• Lightness Races in Orbit: C++: bone simple. Clearly.
• mackenir: C++: if you don't laugh, you'll cry.
• rr-: What about trying to return variables declared as std::unique_ptr<Derived> when function is declared to return std::unique_ptr<Base>? In gcc and mingw-w64 it just works, but vanilla mingw (based gcc 4.9.3, targeting i686-pc-cygwin) needs std::move(x) to compile.
• Steve Jessop: @rr: not sure. I'd expect to need the std::move in that case (because the types don't match and so copy elision is off the table), but I could be overlooking something. The fact it differs between 32-bit and 64-bit mingw is odd. I can't off-hand think of a reason why the compiler or platform authors would intend that.
• rr-: Thanks, that makes sense. Just to make things straight, mingw-w64 is not just a 64-bit version of mingw - it's a fork that introduces some substantial updates.

Answer 2

The move is unnecessary in both cases. In the second case, std::move is superfluous because you are returning a local variable by value, and the compiler will understand that since you're not going to use that local variable anymore, it can be moved from rather than being copied.

• Seth Carnegie: Use of std::move considered harmful, can prevent elision
• Andreas Magnusson: Correction: Use of std::move for return values considered harmful, can prevent elision

Answer 3

There are lots of answers about when it shouldn't be moved, but the question is "when should it be moved?"

Here is a contrived example of when it should be used:

std::vector<int> append(std::vector<int>&& v, int x) {
 v.push_back(x);
 return std::move(v);
}

ie, when you have a function that takes an rvalue reference, modifies it, and then returns a copy of it. (In c++20 behavior here changes) Now, in practice, this design is almost always better:

std::vector<int> append(std::vector<int> v, int x) {
 v.push_back(x);
 return v;
}

which also allows you to take non-rvalue parameters.

Basically, if you have an rvalue reference within a function that you want to return by moving, you have to call std::move. If you have a local variable (be it a parameter or not), returning it implicitly moves (and this implicit move can be elided away, while an explicit move cannot). If you have a function or operation that takes local variables, and returns a reference to said local variable, you have to std::move to get move to occur (as an example, the trinary ?: operator).

• M.M: There is no benefit to using std::move on an int ; maybe this would be a better example if x was a class type with an expensive copy (e.g. appending to a string)
• Yakk - Adam Nevraumont: @M.M Improvement accepted
• hombre: std::vector<int> append(std::vector<int>&& v, int x) { v.push_back(x); return std::move(v); } v in this case can be lvalue reference, wouldn't it put what is referenced by v into "undefined state" ?
• Yakk - Adam Nevraumont: @hombre std::move is just an rvalue cast. v is clearly an rvalue reference, not an lvalue reference; no perfect forwarding can occur here. v is also an lvalue at point of use, so the cast to rvalue reference is needed to ensure this function chains properly. I suspect you have the usual confusion that you think std::move moves things.
• hombre: I double checked. append(std::vector<int>&& v ... ) can only accept an rvalue as v. A caller would be forced to use std::move to call this api. Wouldn't RVO optimize v copy away on the return?

Answer 4

On a return value, if the return expression refers directly to the name of a local lvalue (i.e. at this point an xvalue) there is no need for the std::move. On the other hand, if the return expression is not the identifier, it will not be moved automatically, so for example, you would need the explicit std::move in this case:

T foo(bool which) {
 T a = ..., b = ...;
 return std::move(which? a : b);
 // alternatively: return which? std::move(a), std::move(b);
}

When returning a named local variable or a temporary expression directly, you should avoid the explicit std::move. The compiler must (and will in the future) move automatically in those cases, and adding std::move might affect other optimizations.

• user362515: It should be noted, if one of the params of the ternary is created in-place, it will be constructed into the return variable directly. However a move on it will prevent this. This makes the second alternative more flexible - one will only move the named arg.

Answer 5

A C++ compiler is free to use std::move(foo):

• if it is known that foo is at the end of its lifetime, and
• the implicit use of std::move won't have any effect on the semantics of the C++ code other than the semantic effects allowed by the C++ specification.

It depends on the optimization capabilities of the C++ compiler whether it is able to compute which transformations from f(foo); foo.~Foo(); to f(std::move(foo)); foo.~Foo(); are profitable in terms of performance or in terms of memory consumption, while adhering to the C++ specification rules.

---

Conceptually speaking, year-2017 C++ compilers, such as GCC 6.3.0, are able to optimize this code:

Foo meh() {
 Foo foo(args);
 foo.method(xyz);
 bar();
 return foo;
}

into this code:

void meh(Foo *retval) {
 new (retval) Foo(arg);
 retval->method(xyz);
 bar();
}

which avoids calling the copy-constructor and the destructor of Foo.

---

Year-2017 C++ compilers, such as GCC 6.3.0, are unable to optimize these codes:

Foo meh_value() {
 Foo foo(args);
 Foo retval(foo);
 return retval;
}
Foo meh_pointer() {
 Foo *foo = get_foo();
 Foo retval(*foo);
 delete foo;
 return retval;
}

into these codes:

Foo meh_value() {
 Foo foo(args);
 Foo retval(std::move(foo));
 return retval;
}
Foo meh_pointer() {
 Foo *foo = get_foo();
 Foo retval(std::move(*foo));
 delete foo;
 return retval;
}

which means that a year-2017 programmer needs to specify such optimizations explicitly.

• atomsymbol: @M.M I don't care about C++ terminology in this instance that much. The expression "call to std::move" in the answer has meaning equivalent to "use of std::move".
• atomsymbol: @M.M Do you have further suggestion on how to improve the answer?
• Avin Kavish: @atomsymbol this is a great informational answer, that adds to the existing ones, I don't know what the fuss is about.

Answer 6

std::move is totally unnecessary when returning from a function, and really gets into the realm of you -- the programmer -- trying to babysit things that you should leave to the compiler.

What happens when you std::move something out of a function that isn't a variable local to that function? You can say that you'll never write code like that, but what happens if you write code that's just fine, and then refactor it and absent-mindedly don't change the std::move. You'll have fun tracking that bug down.

The compiler, on the other hand, is mostly incapable of making these kinds of mistakes.

Also: Important to note that returning a local variable from a function does not necessarily create an rvalue or use move semantics.

See here.

• R. Martinho Fernandes: The note in the final paragraph is wrong. The compiler is required to treat it as an rvalue.
• Benj: @R.MartinhoFernandes Yes and no, it will be treated as an rvalue but my compiler prefers elision to move construction and hence it's kind of true to say that there'll be no move semantics (because the move constructor won't be called at all)
• Yakk - Adam Nevraumont: The first paragraph is wrong. It is almost always true that returning std::move is a bad idea, but there exist cases where returning std::move is the right thing to do.