Re: Implementation of shared_ptr

Hi!

fungus wrote:


Yes.


If you want to come around this you should have a look at intrusive_ptr.
It looks a bit complicated to implement the free functions
intrusive_ptr_add_ref and intrusive_ptr_release. But there is a very
simple and generic solution: write a simple abstract base class for the
reference count.

Something like that:

class ref_count
{ friend void intrusive_ptr_add_ref(ref_count*);
   friend void intrusive_ptr_release(ref_count*);
  private:
   unsigned count;
  protected:
   ref_count : count(0) {}
   virtual ~ref_count() {}
  public:
   bool ref_is_managed() { return ref_count != 0; }
   bool ref_is_unique() { return ref_count == 1; }
   // Only a return value of true is thread-safe.
};

void intrusive_ptr_add_ref(ref_count* ref)
{ interlocked_increment(&ref->count);
}

void intrusive_ptr_release(ref_count* ref)
{ interlocked_decrement(&ref->count);
   if (!ref->is_managed())
     delete ref;
}

Now all you have to do for an intrusive reference count is to inherit
from ref_count. This will add the size of the reference count to your
data object, and the intrusive pointer instances are binary identical to
ordinary C pointers. Of course, they are semantically different.
Whether the virtual table pointer of ref_count takes additional space
depends. If your object is polymorphic anyway and you derive from
ref_count without multiple inheritance, there is usually no additional
space required.

If you do not want ref_count to have to have virtual functions all you
have to change is to move the delete operation in a template function
that is aware of the real type of your object. In this case you can
safely downcast ref_count* to your type and delete the result. This will
allow you to use non-polymorphic objects with intrusive_ptr. Of course,
the destructor of ref_count has to be non-virtual in this case.

Note that the above implementation is thread-safe, as long as you
provide appropriate interlocked increment and decrement functions.

Marcel