Re:Catching use-after-move C++ bugs with Clang's consumed an...
by hermitdev on Wednesday July 10, 2019 @01:14PM
(#20404041)
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.
Re:Catching use-after-move C++ bugs with Clang's consumed an...
by foota on Wednesday July 10, 2019 @12:20PM
(#20403412)
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.
Re:Catching use-after-move C++ bugs with Clang's consumed an...
by ori_b on Wednesday July 10, 2019 @02:15PM
(#20404700)
The destructor gets called on them. They need to be valid enough for that.
Re:Catching use-after-move C++ bugs with Clang's consumed an...
by foota on Wednesday July 10, 2019 @05:09PM
(#20406578)
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);
Re:Catching use-after-move C++ bugs with Clang's consumed an...
by 0xffff2 on Wednesday July 10, 2019 @06:51PM
(#20407410)
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.
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.