Boost logo

Boost :

Subject: Re: [boost] request for interest in a garbage collection library
From: Jonas Persson (l.j.persson_at_[hidden])
Date: 2009-04-21 05:25:33

Achilleas Margaritis skrev:
> But gc'd objects are are not supposed to touch other gc'd objects in
> their destructor (if you check the readme, I explicitly say that the
> order of finalization is random). Is there a realistic need to call
> another gc'd object from a destructor?
This isn't about random finalization. It is about that if I have a
reference to a gc object I want to be able to rely on that it is alive
until I release it. I dont want it to be removed under my feet because I
was choosen as the random victim in a circular dependency break up.

A gc object touching other gc'd object in the destructor may not be
common, but the same problem appear even if that other gc object is
accessed inside the destructor of any contained child object or indeed
any function called by any destructor in any object in the dependency
graph. This is not going to be easy to see.

I think you would need to add some sort of guards against this usage,
like assert if any gc_ptr is accessed during garbage collection as Esben
But even then you have to be careful because that will not detect
everything. For example shared_ptr members is often used to make sure
that the lifetime of objects is extended long enough and never accessed
directly. Dropping in gc_ptr in that case will bite you hard.

As I have seen so far, I think the only safe usage of gc is to require a
no circular dependency design.
This is all general issues with garbage collection, and not specifically
about your implementation. I dont really want to discourage you from
continue your efforts to build a gc library, but to be useful in a C++
context all this has to be solved somehow.

   / Jonas

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