Re: [boost] [shared_ptr] dangerous implementation of moveconstructor

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2007-04-16 20:43:45

>    No, but I would expect foo.get_allocator() to return some valid
> allocator and not cause a segmentation fault.  In general, I don't want
> functions that previously were always safe to be unsafe after a move.

If I read you correctly, you want the moved-from object to have exactly the 
same state as an empty one. I don't think this is reasonable requirement in 
general, because a given class may not have an empty state (e.g. it has no 
default constructor) yet it can define proper move semantics (that is, it 
defines "moved from" state even though it does not define "empty" state.)

Specifically for shared_ptr, it does have empty state, and it is perhaps 
reasonable to require that moved-from shared_ptr<T> should behave just like 
an empty one. The main motivation for this requirement seem to be that code 
like:

shared_ptr<T> p( new T );
shared_ptr<T> q( move(p) );
if( p )
    p->foo();

is still valid, e.g. after p has been moved, if(p) would be false.

However, the invariant of shared_ptr is somewhat independent of the 
semantics of T *. The expression "if(p)", as well as dereferencing p, have 
to do with the T * semantics, not with the shared_ptr<T> invariant. This 
basically means that (in general), with or without move semantics being 
considered, for a given shared_ptr<T> p, you can't assume that:

if( p )
    p->foo();

is legal (someone correct me if I'm wrong.)

Therefore, I see no point in requiring that moved-from shared_ptr's state is 
the same as the empty state.

Emil Dotchevski