[boost] Re: shared_ptr co-existence with other smart pointers

From: Gavin Collings (gcollings_at_[hidden])
Date: 2000-03-04 04:53:29

> > 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.
> 
> Yes.

The problem with answering yes to this question is that despite all
good intentions to use best practice, situations occasionally arise
(esp in maintenance) where a more pragmatic approach is necessary.

> After all, if some library function specifies that it wants an
> auto_ptr<> (see example in a previous message), it says "I assume
> ownership and will delete the storage after I'm done".  Now it's
> the duty of the caller to ensure that nobody else has references
> to the pointed-to storage, because it may become invalid any time.
> There is no general way how the caller can achieve this if the
> caller only has a smart pointer variant with shared ownership,
> so mutual agreement in the caller's environment is required (i.e.
> clear documentation and social engineering).

[...]

> Thus, it is not reasonable to initialize an auto_ptr<> with
> a shared_ptr<>.

Well certainly not good practice, but auto_ptr was really just an
example and isn't it a little presumptuous of shared_ptr to assume that
there is no conceivable case in which release of ownership to some
other pointer management scheme is needed.
 
> But, there are shared pointer variants such as linked_ptr<>
> which can inform all other instances that the underlying
> object is no longer managed by this linked_ptr<> cooperative.
> With these, it would be safe to call release(), because
> no other linked_ptr<> will try to delete the data storage,
> and accesses will try to dereference a NULL pointer, with the
> usual implementation-defined *bang*.

As I pointed out previously, boost::shared_ptr is (or can trivially be
made to be) one such 'safe to call release' pointer.

> Let's think about the features we expect from a smart pointer,
> and choose an appropriate implementation:
> 
>  (1) single ownership, noncopyable => scoped_ptr<> (we already
> have get() followed by reset() as a release() substitute for
> scoped_ptr<>, do we want to make that explicit?)

No, get() followed by reset() deletes the contained pointer.  I *do*
want an explicit means of gaining control over what a scoped_ptr
contains.

Gavin.