2 ms·
std::move itself doesn't define what state the object ends up in. The object's type defines that. So it is both undefined (by std::move) and well-defined (by th
by kllrnohj 7y ago
std::move itself doesn't define what state the object ends up in. The object's type defines that. So it is both undefined (by std::move) and well-defined (by the concrete type). The standard simply requires a moved-from object to still have a valid destructor, but types are free to (and do!) allow for more than that to still be valid.
The default move constructor does not zero out the rhs. It simply does a std::move on each of the fields, which for all the primitive types is simply a copy, including for bare pointers. For example this:
struct Foo { int a; void* b; };
int main() {
Foo f{ 20, (void*) 0xBADBEEF };
Foo f2 = std::move(f);
printf("f[%d, %p], f2[%d, %p]\n", f.a, f.b, f2.a, f2.b);
return 0;
}
will print this:
f[20, 0xbadbeef], f2[20, 0xbadbeef]
There is no active zero-ing or "empty" state at any point unless the specific class defines that its move does that. unique_ptr defines that get() will be nullptr after-move, for example, but that's something unique_ptr itself is specifically defining.