Well, that’s just the rub: It’s up to the implementor of a given type to decide what happens to an object that’s been moved-from. They could do something silly

Well, that’s just the rub: It’s up to the implementor of a given type to decide what happens to an object that’s been moved-from. They could do something silly like make a `print(std::string&&)` function which doesn’t actually do anything to the passed-in string, just prints it, but requires callers to `std::move` the arguments, even if it’s not actually moving anything. To C++, there’s no such thing as “moving” per se, there’s just “rvalue references”, and a standard library macro called “std::move” which is really just a static_cast to an rvalue reference. The compiler doesn’t mind if you continue to use something after casting it via std::move. It’s all rather disappointing, really (although I can understand why they did it… backwards compatibility is important in the C++ world.)