[boost] Re: Re: Intrusive smart pointer

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-04-18 12:34:37

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:000d01c1e6f7$5b766180$1d00a8c0_at_pdimov2...
> From: "Fernando Cacciola" <fcacciola_at_[hidden]>
> > > IMO, there is no "standard" intrusive pointer. The variations are (at
> > > least):
> > >
> > > * type of count: public variable, accessor functions, base class;
> > > * name of count/accessors (addref, AddRef, addRef, attach);
> > > * initial value of the reference count (zero or one.)
> > > * delete in the pointer or self-delete in release.
> > >
> > Still, boost could define at least one of these variations.
>
> Sure. Which one? How many complaints will we get that _that one_ was more
> appropriate?
>
FWIW, I've been designing/re-designing intrusive smart pointers for half a
decade now for several team-based projects. From my experience, I would
suggest:

class shared_object
{
  protected :

   shared_object () : m_reference_count ( 0 ) {}
   shared_object ( const shared_object & ) : m_reference_count ( 0 ) {}
   virtual ~ shared_object () {}

   shared_object& operator = ( const shared_object & )
     { m_reference_count = 0 ; return * this ; }

  public :

    void increment_reference_count() const { ++ m_reference_count ; }
    void decrement_reference_count() const
     {
        if ( -- m_reference_count == 0 )
          delete this ;
     }

    bool is_object_shared() const { return m_reference_count > 0 ; }

  private :

     mutable std::size_t m_reference_count ;
} ;

This base class defines the following semantics:

1.Newly created objects starts with a refcount of 0, not 1. This mimics
closer the semantic of a non-intrusive smart-ptr, because once you wrap the
object in a smart-ptr, it will be automatically deleted when the smart-ptr
goes out of scope.

2.The reference counting interface is public. This is required because there
are situations when you need to control the object lifetime manually (from a
bare-pointer). Otherwise, you wouldn't need intrusive refcounting.

3.The reference count is mutable; that is, you can inc/dec reference a const
object. Under this model, the lifetime of the object is not a part of its
state. This allows you to declare smart_ptr<MyClass const>; which is very
useful.

4.The names have been chosen in order to reduce the risk of name collision
with derived classes. The direct usage of this public interface, although
required, is unlikely enough to allow for verbose uncommon names.

5.Shared objects are automatically self-deleted when a call to
decrement_reference_count() makes the count reach zero. This is useful
because it decouples the lifetime control from the smart pointer (The smart
pointer only deals with the shared_object public interface).

So,

although I know that any fixed semantic will left users off, this is already
occurring with the non-intrusive version we currently have. I don't think
that the particular claim of the kind 'why doesn't *this* fit *my* purposes
should prevent a library feature to be added if it can be designed to be
general enough.
My experience have proven to me that a shared object with intrusive-refcount
as I outlined above is general enough to be a lot more useful than not.

--
Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com