Boost logo

Boost :

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

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

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 )

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at