std::move can allow the efficient transfer of resources from object to to object. Andreas Fertig reminds us that using std::move inappropriately can make code less efficient.
The go-to rule is that if you want an object moved instead of copied, you cast the type to a rvalue reference.
The nuance in this article is that return type optimization (RTO) is better than moving, but up until C++17 RTO it was allowed but not guaranteed. Once RTO is enforced, those who care about the tradeoffs between copying and moving are better off leaving compilers doing what they do best.
I guess that it’s important to stress that this is only valid after C++17.
Did you mean to link a different article? This one doesn’t mention RTO at all, just mandatory copy elision and it only shows examples of how moving temporaries is unnecessary (which I was saying should be obvious).
The fact that moving local variables when returning is bad thanks to RTO is a lot less obvious so that’s definitely a useful tip for devs who are still getting the hang of move semantics.
The go-to rule is that if you want an object moved instead of copied, you cast the type to a rvalue reference.
The nuance in this article is that return type optimization (RTO) is better than moving, but up until C++17 RTO it was allowed but not guaranteed. Once RTO is enforced, those who care about the tradeoffs between copying and moving are better off leaving compilers doing what they do best.
I guess that it’s important to stress that this is only valid after C++17.
Did you mean to link a different article? This one doesn’t mention RTO at all, just mandatory copy elision and it only shows examples of how moving temporaries is unnecessary (which I was saying should be obvious).
The fact that moving local variables when returning is bad thanks to RTO is a lot less obvious so that’s definitely a useful tip for devs who are still getting the hang of move semantics.