A move in C++ is a special construct where a new object is allocated in a new memory location and then constructed from the existing object in a way that must guarantee that the existing object is invalidated in some way. This must be handled explicitly in the implementation. For example, for std::vector this means that the move-constructed container steals the internal pointer to the data buffer from the old vector and resets the old vector to empty. This avoids a big and usually superfluous copy operation.

> in a way that must guarantee that the existing object is invalidated in some way

That statement is confusing as the spec very specifically notes that the moved-from object remains valid, so saying that it's invalidated is odd.

You are confusing the now invalid internal state with the continuing existence of an accessible object at the old location. So you can move from an object and then access it. The standard guarantees that the object is still around. But because its data got stolen, its internal state must now be something invalid or empty depending on the semantics of the object.

You’re using way too strong of language. A move in C++ doesn’t require the original object to be invalidated or even modified in any way. POD-ish types, for example, are “moveable” despite not being made empty or invalid after a move (their move is implemented as a copy, which is perfectly valid).

As an example of this, in `boost::asio`, a moved-from socket is in a valid state, and is ready to accept a new connection.

https://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/re...

> You are confusing the now invalid internal state with the continuing existence of an accessible object at the old location.

I'm not confusing anything, and the spec very explicitly notes that a moved-from object is in a "valid but unspecified state", not in an invalid state.

> The standard guarantees that the object is still around.

The standard's guarantees are significantly stronger than that, and furthermore

> But because its data got stolen, its internal state must now be something invalid or empty depending on the semantics of the object.

That is absolutely not a hard rule, a trivial move constructor is a copy constructor and does not affect the moved-from object in any way.

> "valid but unspecified state", not in an invalid state

That's mostly a detail because you can't rely on that to do anything interesting. Basically you can assign a new value to the object, or just destruct it. Having a "valid" but unknown value is completely useless.

What is sad is that the same mechanism has been overloaded for at least 2 different things: simple perf optim (when you fall into this situation of no guarantee), and movable unique ownership (like unique_ptr) where you actually can read the resulting object after the move an expect a predictable (in a portable and standardized way ) outcome.