On 4/5/2011 1:50 PM, Dominique Devienne wrote:
On Tue, Apr 5, 2011 at 3:04 PM, Phil Bouchard<philippe@fornux.com> 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