5 ms·
> 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 re
by innot 7y ago
> 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.
- foota 7y agoI 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 7y agoThe destructor gets called on them. They need to be valid enough for that.
- foota 7y agoHm, 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 7y agoYes, 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.
- hermitdev 7y agoYes, 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.
- olliej 7y agoValid for the purpose of calling the destructor. That’s the only requirement. The actual semantic state of the object may not make sense.