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

Subject: Re: [boost] request for interest in a garbage collection library
From: Achilleas Margaritis (axilmar_at_[hidden])
Date: 2009-04-20 18:45:25

Simonson, Lucanus J wrote:
> Achilleas Margaritis wrote:
>> The reason for using a GC is to be relieved from having to think about
>> potential referential cycles. One nasty problem is cycles inserted via
>> subclassing. There can go undetected very easily, especially if the
>> subclass containing the cycle is introduced indirectly (this is a
>> real-world issue that had happened to my company some times).
>>
> --snip--
> 
>> The only case that is unsolvable is the case where there is a cycle,
>> since in that case it is not possible to tell where is the start of
>> the graph. In this case, the gc will have to take an arbitrary
>> decision and 
>> start the finalization from a random graph node.
> 
> I may not understand all the issues as well as you clearly do, but it appears to me you are contradicting yourself.  You state that GC frees you from having to think about reference cycles, but you don't currently allow such references, and if you did you wouldn't be able to resolve cycles anyway.  I don't see how any problem is actually solved here.  I am already free from having to think about reference cycles because I avoid the design patterns that lead to them..  For code that already works that way I don't know that introducing GC into the mix to try to resuce it will make the soup taste any better.  Man, I've made some bad soup that way, just keep adding good ingredients hoping it will make it taste less terrible, but all you get in the end is even more bad tasting soup.  For code th
>  at is already broken, it is probably better to take something out of the software design than add something new (or a new overload of new, as the case may be.)

The collector allows for cycles. What it does not currently allow is 
referencing gc'd objects in the destructor.