[boost] Re: Garbage Collection, Reference Count or Ownership?

From: cppljevans_at_[hidden]
Date: 2003-10-05 12:14:01

On 10/05/2003 11:31 AM, Douglas Gregor wrote:
> On Sunday 05 October 2003 10:03 am, Philippe A. Bouchard wrote:
[snip]
>>If someone wrote his program with shifted_ptr and suddenly decides to
>>accelerate his program he could simply define this macro, recompile & tada!
>>it works like a normal reference count smart pointer & becomes faster.
> 
> 
> Garbage collection can be faster than reference counting, but it all depends 
> on usage patterns. For instance, my GC-needing application has a phase where 
> it allocates a ton of memory, much of which won't be needed later. The next 
> phase runs over the internal representation many times (typical 
> compiler/static analyzer behavior). Reference-counting would be a killer 
> here, because in the second phase we incur all of the overhead of reference 
> counting but get little benefit from it, because memory isn't being 
> allocated/deallocated much.
suif uses a preprocessor called hoof which, IIRC, constrains the
"owning" pointers to form a tree.  Since it's a tree, deletion
is fast and there's no gc.  However, this can lead to dangling
pointers (IIRC).  This problem can be overcome with smart_ptr's
of 2 types, single_owners, and weak_owners.  A few weeks back
someone else (Oliver.Schoenborn_at_[hidden]) was asking
about feedback on this idean of single_owners.  The solution
I'm thinking of is that adopted polaris.  The weak_ptr DTOR
does maintain a reference count.  When that goes to 0, the
memory is collected. When it's non-zero, an exception is raised.
This is because the single_owner has been destroyed. Now, as
you say, this maintenance of the refcount in the weak_ptr's
could be time consuming during production runs; however, as
Philippe notes, it would be nice to detect errors early and
easy during development. This advantage was illustrated by
my experience with polaris when the gc wasn't working correctly
and leaving weak_ptr's pointing to what should have been
destructed objects.  After the gc was corrected, these references
showed the developer where the problem was (I got this second hand,
so I'm imaging what the circumstances were). Maybe something
like this with same way to switch the weak_ptr<check,T> to
weak_ptr<nocheck,T> in production code would be useful.  Philippe's
suggestion of a macro is one way, or a class static variable would
be the way to go.  In short, I do think the abililty to switch from
"debug weak_ptr" to "production weak_ptr" is a good idea.