Re: [boost] [shifted_ptr] Review Request

Subject: Re: [boost] [shifted_ptr] Review Request
From: Phil Bouchard (philippe_at_[hidden])
Date: 2011-04-05 18:34:37

On 4/5/2011 1:50 PM, Dominique Devienne wrote:
> On Tue, Apr 5, 2011 at 3:04 PM, Phil Bouchard<philippe_at_[hidden]>  wrote:
>> No shifted_ptr<>  uses its own memory management strategy on top of reference counting.
>
> Phil, can you please explain the rational for the name shifted_ptr<>?
> Sounds more like a "managed" ptr to me, and don't see how that relates
> to "shifted".

In contrast with shared_ptr<> which has one pointer to the object and 
another one to the reference count, shifted_ptr<> only has one pointer 
to the object.  The object is a member inside shifted<> and the 
reference count is accessed by shifting the pointer up to the reference 
count, a member preceding the object (defined in sp_counted_base). i.e.:

class sp_counted_base // pointee header
{
     int use_count_;
     int weak_count_;
     ...
};

class owned_base : public sp_counted_base // pointee header
{ ... };

template <typename T>
     class shifted : public owned_base // pointee
     {
         T elem_;
     };

template <typename T>
     class shifted_ptr_common // pointer
     {
         T * po_; // directly points to a shifted<T>::elem_
         ...
         owned_base * header()
         {
             // returns the counter by shifting "po_" up
         }
     };

> Having done Java for a few years, I understand the GC concept you
> described in your previous post (wondering how you achieve O(1) ops
> and immediate destruction though :) ) and that you guarantee object
> one references won't be deleted, but the flip side is that unwanted
> references can prevent the whole ball-of-wax from ever being GC'd.
> There are several tools in Java to find those "reference" leaks, which
> is tricky in large applications, especially GUI ones. How does one
> tackle this issue with your _ptr<>?

A smart pointer object has the count of the number of pointers pointing 
to the object.  shifted_ptr<> also has a set counter; a set counter has 
the count of the number of pointers from the stack referencing to the 
set.  Thus when no pointers from the stack are referencing the set 
anymore then the set is being destroyed instantly.

> Finally, when a "set" is GC'd, in which order are it's elements
> deleted? Of particular interest is the case with cycles of course. Is
> a "stale" _ptr<>  (what it points to, in the same "set", was already
> deleted) in the soon-to-be deleted object reset to null implicitly
> kinda like weak_ptr<>?

The elements inside a set are being destroyed in the reverse order they 
were constructed.  The destruction of a cyclic set is done by forcing 
all elements to be destroyed and disregards reference counts.

Thanks,
-Phil