[innot]

> Once you std::move an object and pass it to someone who takes an rvalue-reference, your local object may very well end up in an invalid state.

As far as I remember, move constructors/assignments must leave the moved-from object in a valid state - just that the standard doesn't say anything about what that state is for standard classes.

Also, I have seen code where some kind of "result" can be moved from an object and then re-generated from scratch with different inputs. In that case it was perfectly valid to use it after move. But that's nitpicking, anyways.

[hermitdev]

Yes, valid, but unspecified. Typically what I've seen is that a move operation is effectively a swap between the source and destination. I've also seen where a move leaves the source in effectively a default constructed state.

[foota]

I believe the standard says that move does "valid but unspecified" for standard library objects, but does not generally guarantee that moved from objects must be valid.

[ori_b]

The destructor gets called on them. They need to be valid enough for that.

[foota]

Hm, technically don't think this would be required. Take for instance:

  auto no_destroy = new MoveNoDestroy();

  MoveNoDestroy* moved_into;

  *moved_into = std::move(*no_destroy);

Wouldn't call the destructor of the moved from MoveNoDestroy.

[0xffff2]

Yes, if you leak resources, their destructors won't be called. That really has nothing at all to do with move semantics though. I think the important point is that move semantics don't alter the lifetime management of the moved-from object.

[olliej]

Valid for the purpose of calling the destructor. That’s the only requirement.

The actual semantic state of the object may not make sense.