Re: [boost] request for interest in a garbage collection library

Subject: Re: [boost] request for interest in a garbage collection library
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-04-20 14:43:47

Achilleas Margaritis wrote:
>> Jumping in here, the problem is that having to mix GC code, which
>> automatically releases memory in a non-deterministic way, and normal
>> RAII destructor code, which releases all resources in a deterministic
>> way, creates two different syntaxes in a C++ program. This would
>> currently require the programmer to "know" which type of destruction
>> belongs with which object.
> 
> I think the overhead of knowing which type of destruction belongs to
> which object is minimal when compared to the overhead of manually
> tracking memory. Resources like memory should be tracked by a GC,
> resources like mutexes or files should be tracked by RAII.
> 
> What I like in C++ is that I can use the best of both worlds at the
> same time.
 
Really?  Memory should be tracked by GC and not RAII?  Why?  The only reason GC is even acceptable for managing memory is because memory is a very plentiful resource in most systems.  RAII covers 90% of cases of memory allocation and in the other 10% I don't find managing it manually to be too much of a burden, and if I wanted to be lazy I could use shared pointers to do the reference counting instead of using a GC library with equal extra effort.  I don't want to be lazy, and I don't want to debug problems in code that mixes and matches GC and non-GC objects and leaves it very ambiguous whether someone forgot to call delete. 

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

Saying your documentation states that GC objects shouldn't manipulate GC objects in their destructors is all well and good, but that won't stop people from doing it, and it won't stop their code from working when they test it and breaking later when it is used.  If you could enforce such a thing with a compilation error using some template meta-programming trick that would be mildly interesting, but just saying its not supported and letting everyone who won't bother to read the documentation find that out the hard way is not good design because it is error prone.  Just because the problem can't be solved doesn't mean there isn't a real problem here.

I can't think of a way to get a syntax error in the case that code is compiled when in the context of a destructor, but not otherwise.  You are giving people a hammer, a blindfold and a box of nails and telling them to be careful not to hit their thumbs.  That's not the best of both worlds.

Luke