Peter Dimov wrote:
Ion Gaztañaga wrote:
For objects that have no such default-state, and have no resource reassignment functions (like reset() or similar) there is no problem because there is no interface to reuse the object.
I think I was with you until this point. It seems to me that the exact opposite is true; objects that have no "empty" or "default" state cannot implement a move, at least not easily, whereas reusing a moved-from object via assignment or reset is no problem at all.
Ok. So if such objects can't be moved, there is no problem to offer reusability for other objects that can be moved ;-)
FWIW, I've changed the shared_ptr move constructors and assignment operators to leave the source empty, but this doesn't mean that I'm convinced that the general case needs to be constrained in such a way. In particular,
T& operator=( T && r ) { swap( r ); return *this; }
seems a very reasonable implementation of move assignment, and has a slight performance advantage (one call to ~T instead of two in a typical use case) over
T& operator=( T && r ) { T( move( r ) ).swap( *this ); return *this; }
which is what is needed for r to be left empty.
Ok. Forget about the default constructed state. I don't want you to deallocate the heap allocated reference count (you know I'm the leader of the anti-allocate religion). Just tell me if move in terms of swapping can lead to reusability. Does it make any sense? If it does not, can you find a way so that you get swap semantics *and* reusability is possible? The default-constructed state was just a possibility, not the goal. My goal is to left the objects in a consistent, usable state. If resources from the previous move target have been stolen so that we can reuse them, even better. Regards, Ion