The parts that seem likely to cause this confusion (which I shared when I first started using C++11) are:
Moves in C++ are always a potentially-destructive operation on a reference, not just a memcopy.
Consequently, “moving” a temporary still requires having two separate instances of the type, despite that generally not being what you want, hence RVO.
…but move-semantics are generally presented and understood as an “optimization”, and conceptually “take the guts of this value and re-use them as a new value” is both what RVO is doing and what move-semantics are doing.
std::move isn’t a compiler intrinsic and doesn’t force a move operation; it’s just a function that returns an r-value reference. So it makes it harder, not easier, for the compiler to “see through” and optimize away, even in the case where “as if” rule should make that legal.
The parts that seem likely to cause this confusion (which I shared when I first started using C++11) are:
std::moveisn’t a compiler intrinsic and doesn’t force a move operation; it’s just a function that returns an r-value reference. So it makes it harder, not easier, for the compiler to “see through” and optimize away, even in the case where “as if” rule should make that legal.