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

From: Douglas Gregor (gregod_at_[hidden])
Date: 2003-10-04 18:30:41

On Saturday 04 October 2003 06:02 pm, Philippe A. Bouchard wrote:
> Hi Boost,
>
>     I am currently revising shifted_ptr<> and I am asking myself if it is
> worth keeping three distinct cyclic reference solutions.  Let's analyse the
> situation:
>
>
> 1) shifted_ptr is optimized purely for garbage collection:
>
> + cyclic references on the heap will automatically be deleted;
> + simpler to integrate with the policy based design;
> - impossible to accelerate destruction of known cyclic references
> explicitly;
> - the garbage collector will have to be quite fast if kept as the default
> solution.

Personally, I'd like to have one of these types. I don't care if it's called 
shifted_ptr, gc_ptr, or lazy_bum_ptr; it would help me greatly :)

> 2) shifted_ptr keeps the collector_traits<> class in order to associate
> classes with their specific cyclic solution:
>
> + now possible to define at compile-time which method the developer prefers
> using for a given class;
> + the design is defined only once and is class oriented;
> + don't have to create yet other smart pointers to handle those different
> garbage solutions;
> - more difficult to integrate with new designs eventually;
> - cannot cast a shifted_ptr of type ownership with a garbage collected one.

One comment I neglected to make about using traits to determine how to store 
the item: people commonly use smart pointers where they don't the pointee 
class definition, which often mains they don't have the traits. Which means:

// foo1.cpp
class Pointee;
// copy shifted_ptr<Pointee>'s around and such

// foo2.cpp
#include "Pointee.h" // get definition with traits
// do stuff with shifted_ptr<Pointee>

foo1.cpp and foo2.cpp both have shifted_ptr<Pointee>'s that act differently, 
causing very bad things to occur. The moral? Don't use traits to decide 
anything unless you also require the full definition of the class, or encode 
the policy in the shifted_ptr type.

> It would be a lot simpler to concentrate on garbage collection issues but
> in this case I would like some BOOST_GC_DEACTIVATE macro and the ability to
> explicitly destroy a cyclic entity on the heap.
>
> Any thoughts?

I think it might be more fruitful to concentrate on a good, garbage-collected 
pointer. Two questions on this:

  1) Do you really need BOOST_GC_DEACTIVATE, if could users just instead 
switch over to something like shared_ptr if they really don't want to use GC? 
There's no need to allow (or require users to understand) customization when 
alernatives already exist.

  2) The ability to explicitly destroy (or break) cycles would be very nice to 
have. Have you considered something akin to weak_ptr, that allows references 
but doesn't keep the target alive? (Note: I haven't thought about the 
implementation this _at all_, so I'll understand completely if you say it's 
infeasible or too costly).

        Doug