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". 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<>? 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<>? Thanks, --DD