|
Boost : |
Subject: Re: [boost] [shifted_ptr] Review Request
From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2011-04-05 16:50:27
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".
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk