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