[boost] shared_ptr co-existence with other smart pointers

From: Gavin Collings (gcollings_at_[hidden])
Date: 2000-03-03 08:36:01

> 
> Boosts shared_ptr<TYP> seems to address the problem, but I've found no 
> way to modify its value since there is no release() capability. get() 
> followed by reset() results in a dangling pointer, and swap() just 
> postpones the agony. I can't seem to convert shared_ptr => auto_ptr.
> 

The above highlights a need for boost::shared_ptr<> to co-exist with other smart
pointer implementations.  The current 'policy' for boost::shared_ptr<> seems to
be that it will accept ownership from raw pointers or std::auto_ptr<>, but will
never give it back again.  Since boost::shared_ptr<> and its kin only implement
a sub-set of conceivable desired ownership semantics, this seems overly
restrictive.  Presumably, as the trend towards using various smart pointers to
support exception safety continues, this will become increasingly so.  The
options seem to be: -

1) Insist on the current policy, shared_ptr is closed (or at least as closed as
it can be).  Use shared_ptr in cases where auto_ptr would normally be used.

2) Accept the need to open up ownership to other shared_ptr implementations. 
This can be handled fairly neatly by supplying a release() method.  This has
already been proposed for linked_ptr; it could easily be incorporated into
shared_ptr.  I'm still in two minds whether it's best to allow this operation in
situations where more than one smart pointer is involved (probably not).

Supplying explicit methods to convert to other known smart pointers (e.g.
release_as_auto_ptr) would be largely redundant, since most (all?) smart
pointers will have a constructor taking a raw pointer anyway.

Another way of handling this, may be by using a proxy class, along with suitable
conversion operators, to handle conversions and transfer of ownership.  Consider

   void f( boost::shared_ptr<int> );
   void g( boost::shared_ptr<int> );

   boost::scoped_ptr<int> scpi( new int( 0 ) );
   func( scpi.release() );
   // can't use scoped_ptr here.

could be replaced by something like

   f( ptr_proxy_inout( scpi ) );
   // can use scoped_ptr here.
   g( ptr_proxy_in( scpi ) );
   // but not here.

or maybe even in the functions themselves

   void f( ptr_proxy_inout<int> );
   void g( ptr_proxy_in<int> );

ptr_proxy_xxx would transfer ownership to the shared_ptr on the way in and back
again, if necessary in its destructor, on the way out.  One benefit is that it
allows a degree of self documentation as to the intended ownership of the
contained pointer.

Thoughts anyone?

Gavin.