OSNews article about C++09 degenerates into C++ vs. D discussion

[Steve Horne]

On Mon, 20 Nov 2006 17:25:26 +0100, Frits van Bommel
<fvbommel at REMwOVExCAPSs.nl> wrote:

>> Cyclic references is a problem only when using GC. If the programmer
>> wants to use a malloc-based allocation, he knows he should handle cyclic
>> references himself. Not a problem.
>
>Actually, cyclic references are not a problem for GC. Not having to 
>handle them is in fact one of the benefits of GC, or (depending on how 
>you look at it), having to handle them is a problem with reference counting.

The problem is ensuring proper cleanup, such as closing files,
releasing handles and locks, etc when using an RAII approach. The GC
cannot know what order to do the destructors/finalisers/whatever in.
The Java solution is not to bother - it doesn't guarantee that
finalisers will be called.

BUT - how do cyclic references occur in relation to slicing? It sounds
very odd. I can certainly see the point of chains (slices of slices)
but I can't see how cycles could arise at all.

Cycles are only common in certain types of programming, such as data
structure handling (which should normally be packaged up in a
container library). They can happen in user interface stuff (child and
parent windows having references to each other) but even this should
be easily avoidable. Don't save the parent/child references in your
own objects - trust the platforms GUI data structures and request the
references you need when you need them.

-- 
Remove 'wants' and 'nospam' from e-mail.