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

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2003-10-05 09:03:37

Douglas Gregor wrote:

[...]

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

lazy_bum_ptr<> will have to be negociated ;)

[...]

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

Yeah this is also true.  Let's discuss the "ownership" paradigm:

+ perfect solution for 1d / 2d / nth d containers, ropes, neural networks,
etc.;
+ is able to play the role of an auto_ptr<> and a weak_ptr<> at the same
time;
- it is possible to create dangling smart pointers in this case (dangling
"weak_ptr<>s");
- cannot be easily casted to other pointee types.

[...]

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

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.

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

This sounds a little bit like the ownership concept.

As for explicit destruction, it could create dangling smart pointers but it
would be at the user's discretion to perform the call.

Philippe