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

by

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.

More Related Contents:

  1. What is “rvalue reference for *this”?
  2. How to enforce move semantics when a vector grows?
  3. C++11 rvalues and move semantics confusion (return statement)
  4. initializer_list and move semantics
  5. What is the advantage of using forwarding references in range-based for loops?
  6. Reusing a moved container?
  7. Move assignment operator and `if (this != &rhs)`
  8. What does the standard library guarantee about self move assignment?
  9. Is a moved-from vector always empty?
  10. Why does std::move prevent RVO (return value optimization)?
  11. How to actually implement the rule of five?
  12. Does moving leave the object in a usable state?
  13. Why do we copy then move?
  14. Initializer-list-constructing a vector of noncopyable (but movable) objects
  15. Should I delete the move constructor and the move assignment of a smart pointer?
  16. copy vs std::move for ints
  17. Is an object guaranteed to be moved when it is returned?
  18. Why do you use std::move when you have && in C++11? [duplicate]
  19. Do built-in types have move semantics?
  20. Is there any case where a return of a RValue Reference (&&) is useful?
  21. When to make a type non-movable in C++11?
  22. Is std::array movable?
  23. C++11 virtual destructors and auto generation of move special functions
  24. Should the Copy-and-Swap Idiom become the Copy-and-Move Idiom in C++11?
  25. When is explicit move needed for a return statement?
  26. Move out element of std priority_queue in C++11
  27. Why would I std::move an std::shared_ptr?
  28. Should all/most setter functions in C++11 be written as function templates accepting universal references?
  29. Move semantics == custom swap function obsolete?
  30. What is use of the ref-qualifier `const &&`?

Leave a Comment