Boost logo

Boost :

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).


Boost list run by bdawes at, gregod at, cpdaniel at, john at