"So in a sense, we have drifted into the netherworld of non-deterministic destruction here: a variable has been assigned to, but the object formerly held by that variable is still out there somewhere. That's fine as long as the destruction of that object does not have any side effects that are visible to the outside world. But sometimes destructors do have such side effects. An example would be the release of a lock inside a destructor. Therefore, any part of an object's destruction that has side effects should be performed explicitly in the rvalue reference overload of the copy assignment operator:
1 2 3 4 5 6 7 8 9 10 11
X& X::operator=(X&& rhs)
// Perform a cleanup that takes care of at least those parts of the
// destructor that have side effects. Be sure to leave the object
// in a destructible and assignable state.
// Move semantics: exchange content between this and rhs
What does it mean release the lock on a destructor and cleanup? Can someone please help!
X b ;
X a ;
// do stuff...
a = std::move(b) ;
// If we wanted to access a resource here that was previously restricted by a
// and it wasn't released by the move assignment operator, we're out of luck since
// it will remain locked until (assuming it was swapped and not leaked) b's destructor
// is invoked somewhere below.
// do more stuff...
} // b is destructed here.