Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at