dsimcha wrote:
== Quote from grauzone (n...@example.net)'s article
Rioshin an'Harthen wrote:
"Leandro Lucarella" <llu...@gmail.com> kirjoitti viestissä
news:20090411030416.ga22...@homero.springfield.home...
BTW, is there any real interest in adding some more power to the GC
implementator to allow some kind of moving or generational collector?
What I mostly want/need from the GC would be determinism. I want to be
able to call delete on a subobject in the destructor of the object being
deleted.
How many times have I stumbled on this already?
Actually, this isn't needed:
- if you want to manually free an object, you can add an extra destroy()
method
- when the object is garbage collected, there's no point in deleting
referenced objects, because these are either still alive, or get
collected as well
In theory true, but in practice false. If you have a huge array owned by a
small
class, the huge array can be retained due to false pointers. Before I realized
that it's illegal, I used to put delete statements in destructors in these kinds
of situations and it seemed to work in practice even though it's illegal
according
to the spec, although I never tested it rigorously or really thought about how
it
could break.
Then you should simply use malloc.