Best practices for returning objects using move semantics inside the c++11 function

In a word, return directly, without any change.

When the C++11 option is started, no changes have occurred through the function return code, but the move semantics have been used without requiring the previous Nrvo compiler optimization techniques.

Note that the Rvalue reference rvalue reference is a temporary variable that no longer exists after the expression is evaluated, and the left value is the variable after the expression is evaluated. If you can use & to address, it is the left value.

Here is a discussion sticker on StackOverflow, which is more valuable:

246down voteaccepted

First example STD::Vector<int>Return_vector(void){STD::Vector<int>tmp{1,2,3,4,5}; returntmp;}STD::Vector<int> &&Rval_ref=Return_vector(); The first example returns a temporary which is caught by rval_ref . That temporary'll has the IT life extended beyond the definition and your rval_ref can use it as if you had caught it by valu E. Very similar to the following: const std::vector<int>& rval_ref = return_vector(); Except that in my rewrite you obviously can ' t use Rval_ref in a non-const manner. Second Example STD::Vector<int>&&Return_vector(void){STD::Vector<int>tmp{1,2,3,4,5}; returnSTD::Move(tmp);}STD::Vector<int> &&Rval_ref=Return_vector(); The second example you have created a run time error. Rval_ref now holds a reference to the destructed tmp inside the function. With any luck, this code would immediately crash. Third example STD::Vector<int>Return_vector(void){STD::Vector<int>tmp{1,2,3,4,5}; returnSTD::Move(tmp);}STD::Vector<int> &&Rval_ref=Return_vector(); Your Third example is roughly equivalent to Your first. The Std::move on TMP are unnecessary and can actually be a performance pessimization as it would inhibit return value Optimi Zation. The best-by-code what are you ' re doing are: Best Practice STD::Vector<int>Return_vector(void){STD::Vector<int>tmp{1,2,3,4,5}; returntmp;}STD::Vector<int>Rval_ref=Return_vector(); i.e. just as you would in C++03. TMP is implicitly treated as a rvalue in the return statement. It'll either is returned via Return-value-optimization (no copy, no move), or if the compiler decides it can not perform RVO, then it'll use Vector's move constructor to do the return. Only if RVO are not performed, and if the returned type does not has a move constructor would the copy constructor be used For the return. Shareeditflag answered "at 20:52Howard hinnant 74.1k145 251

6 great thanks for the elaborated answer! –tarantula ' at 17:10 10 compilers would RVO when you return a local object by value, and the Ty PE of the local and the return of the function is the same, and neither is cv-qualified (don ' t return const types). Stay away from returning with the condition (:?) statement as it can inhibit RVO. Don ' t wrap the Local in some other function this returns a reference to the local. just  return my_local; . Multiple return statements is OK and would not inhibit RVO.  –  howard hinnant feb "at 20:18 3 There is a caveat:when returning a member of a local object and the move must be explicit. –boycy ' at 8:58 4 @NoSenseEtAl: There is no temporary created on the return line.   Move  doesn ' t create a temporary. It casts an lvalue to a xvalue, making no copies, creating nothing and destroying nothing. That example are the exact same situation as if you returned by lvalue-reference and removed the  move &nbs P;from The return line:either you ' ve got a dangling reference to a local variable inside the function and which have B Een destructed.  –  howard hinnant feb "at 16:11 1 Upvote Flag Just a nit:since you named the variable ( tmp ) in the ' Best Practice ' section, it's the NRVO that kicks in , not the RVO. These is different optimizations. Other than, great answer! –daniel Frey Feb

I returned to VECTOR<STRING> in the process of the previous few days, when I encountered the core dump, replaced by the vector<string> & output parameters of the way to solve. Further tracking is required, whether it is a bug of clang++ 3.5.

Best practices for returning objects using move semantics inside the c++11 function