Why does std::move prevent RVO (return value optimization)?

by

The cases where copy and move elision is allowed is found in section 12.8 §31 of the Standard (version N3690):

When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the constructor selected for the copy/move operation and/or the 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):

  • in a return statement in a function with a class return type, when the expression is the name of a non-volatile automatic object (other than a function or catch-clause parameter) with the same cv-unqualified type as the function return type, the copy/move operation can be omitted by constructing the automatic object directly into the function’s return value
  • […]
  • when a temporary class object that has not been bound to a reference (12.2) would be copied/moved to a class object with the same cv-unqualified type, the copy/move operation can be omitted by constructing the temporary object directly into the target of the omitted copy/move
  • […]

(The two cases I left out refer to the case of throwing and catching exception objects which I consider less important for optimization.)

Hence in a return statement copy elision can only occur, if the expression is the name of a local variable. If you write std::move(var), then it is not the name of a variable anymore. Therefore the compiler cannot elide the move, if it should conform to the standard.

Stephan T. Lavavej talked about this at Going Native 2013 (Alternative source) and explained exactly your situation and why to avoid std::move() here. Start watching at minute 38:04. Basically, when returning a local variable of the return type then it is usually treated as an rvalue hence enabling move by default.

More Related Contents:

  1. Move or Named Return Value Optimization (NRVO)?
  2. What is move semantics?
  3. push_back vs emplace_back
  4. How to enforce move semantics when a vector grows?
  5. What is std::move(), and when should it be used?
  6. What can I do with a moved-from object?
  7. Can I list-initialize a vector of move-only type?
  8. How do I use a custom deleter with a std::unique_ptr member?
  9. Reusing a moved container?
  10. Why no default move-assignment/move-constructor?
  11. What constitutes a valid state for a “moved from” object in C++11?
  12. Move assignment operator and `if (this != &rhs)`
  13. What are the rules for automatic generation of move operations?
  14. Why is `std::move` named `std::move`?
  15. C++11 move constructor not called, default constructor preferred
  16. Is the pass-by-value-and-then-move construct a bad idiom?
  17. Move-only version of std::function
  18. How does std::move() transfer values into RValues?
  19. Is it possible to std::move objects out of functions? (C++11)
  20. Why do some people use swap for move assignments?
  21. Non-copyable elements in vector
  22. Can I typically/always use std::forward instead of std::move?
  23. Is a `=default` move constructor equivalent to a member-wise move constructor?
  24. copy vs std::move for ints
  25. In C++, is it still bad practice to return a vector from a function?
  26. Should the Copy-and-Swap Idiom become the Copy-and-Move Idiom in C++11?
  27. Why would I std::move an std::shared_ptr?
  28. C++: std::move with rvalue reference is not moving contents
  29. What is std::move(), and when should it be used and does it actually move anything?
  30. What is use of the ref-qualifier `const &&`?

Leave a Comment