Comment by innot | Hacker News Reader

Comment by innot | Hacker News Reader

Parent Full thread

> 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.

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.

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.

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

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.

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.

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

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

Reply on news.ycombinator.com