Re: [boost] [shared_ptr] dangerous implementation of move constructor

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2007-04-16 13:33:23

Howard Hinnant wrote:
> 
> [snip]
> 
> There is nothing in the rvalue ref proposals that really nails this  
> down.  It is up to each class to define its behavior after a move.   
> At the very least it should support assignment and destruction in  
> order to work with generic code.  Beyond that I'd say the class  
> should be free to implement whatever semantics / interface it feels  
> best.

I respectfully disagree ;-) If the object is still there and can be used 
it should be usable. If we had destructive move-semantics, I would agree 
that the state of the objects should be undefined (or even better, 
destroyed), but in that case I would expect compiler help to detect uses 
of move-destructed variables after the move-destruction.

std::vector<T> myvect(...);
//myvect's destructor is called, the object is not longer usable
std::vector<T> myvect2(std::destructive_move(myvect));
myvect.resize(1000); <-- COMPILATION ERROR

In my opinion, the standard should clearly say what happens with an 
standard component. An example: what's the state of an STL container 
after being moved?

std::vector<T> myvect(...);
std::vector<T> myvect2(std::move(myvect));
myvect.resize(1000); <-- is this correct?

If myvect is allowed to be in a non-usable state, the allocator might be 
moved from myvect to myvect2. If myvect should be usable, the allocator 
should be copied --> corollary: If we want non-throwing move 
constructors and assignments (which is surely required for objects we 
want to place in STL containers, like std::list<std::vector<T> >) 
allocator copying shouldn't throw.

If the standard does not specify anything, implementors of allocators 
must always support the worst case (copying shouldn't throw) but they 
can't use the advantages (the vector is NOT reusable). Users also get 
the worst of both worlds.

Since current move semantics are non-destructive the state of the object 
should be usable. For objects that have a default-constructor (like 
shared_ptr or vector) the moved state could be equal to 
default-constructed (which is consistent *and* usable). And no-throw 
guarantee should be required for such move operations

This might complicate a bit the implementation of allocators, but it's 
perfectly possible to achieve this with containers. For shared_ptr, I 
don't know if the state should be default-constructed, but I would like 
to reuse that object via reset().

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. For objects that 
don't have default-constructor but have resource reassignment functions, 
the state might be undefined, but I would require object reuse 
capability. In any case, you need to internally maintain the "moved" 
state so that the destructor does not crash the program. Since we have 
to pay some price (the zombie state, if you want to call it), let's take 
something in return.

My 2 cents,

Ion