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

From: Jens Maurer (jmaurer_at_[hidden])
Date: 2000-03-04 06:42:26

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

The approach must be a bit more complicated than previously
mentioned. We cannot simply set the usage count to some fixed
value saying "don't delete", because we need to delete the
usage count itself in the end, which is a dynamic object in the
current shared_ptr<> implementation.  So we need two different
usage count barriers: If we reach barrier one, it says "delete the
object and the usage count" (this is currently the value 0), if we
reach the other, it says "delete the usage count (only)". This is
an additional conditional in every destructor call.  I would like
to see code for this subjected to some performance tests.

Paul Jensen suggested a copied_ptr<>, which copies the value
pointed to if someone wants exclusive ownership.  Is there any
feeling how useful this would be in practice to avoid a
shared_ptr<> => auto_ptr<> conversion?  It's certainly better
than any other release() hackery.

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

Sorry, I got the facts wrong. We should add release() to
scoped_ptr<>, because it has none of the issues we're talking
about.

Regarding the maintenance argument, we're basically discussing what
kind of smart pointer (which fulfills STL container element requirements)
we should recommend to the average user so that there are sufficient
options for later maintenance.  For that, I would recommend some
smart pointer with immediate notification of lost ownership to all
members of the cooperative.

But please don't remove the other smart pointers for those who
have different requirements.

Jens Maurer