Is this correct usage of C++ 'move' semantics?

Question

Tonight I\'ve been taking a look at some code I\'ve been working on over the last few days, and began reading up on move semantics, specifically std::move. I have a few que

Answer 1

To add to GMan's answer: even if you change the return type to be std::vector (without any references, otherwise you'll get UB), your change of return expression in "1)" will never make the performance better, but might make it a bit worse. As std::vector has move constructor, and you return a local object, vector's copy constructor will not be called, no matter you wrote return theVector;, return static_cast&&>(theVector);, or return std::move(theVector). In the last two cases the compiler will be forced to call the move constructor. But in the first case it has the freedom to optimized out the move altogether, if it can do NRVO for that function. If NRVO isn't possible for some reason, only then the compiler will resort to calling the move constructor. So don't change return x; to return std::move(x); if x is a local non-static object in the function being returned from, otherwise you'll prevent the compiler from using another optimization opportunity.