Re: New C++ garbage collector
On Oct 27, 11:32 am, Leigh Johnston <le...@i42.co.uk> wrote:
On 27/10/2010 11:12, James Kanze wrote:
On Oct 26, 6:38 pm, Leigh Johnston<le...@i42.co.uk> wrote:
On 26/10/2010 18:15, Bo Persson wrote:
Leigh Johnston wrote:
On 26/10/2010 17:26, Paavo Helde wrote:
SG<s.gesem...@gmail.com> wrote in
news:bcb74c08-83ae-4c1f-aef3-84df7eb02bb6@u10g2000yqk.googlegroups.com:
It seems like an interesting concept. Your GC is even
trying to invoke destructors, though, I would feel uneasy
about this in a multi- threaded application.
There was a looong thread about this several years ago (here or in
clc++m, don't remember). I got an impression that the firm
consensus was that gc should not call destructors - logically the
lost objects would live forever, only the memory is reclaimed and
recycled. This seems to be the only way to make the program
behavior deterministic.
Resulting in resource leaks? Seems pointless to me.
The idea is that gc solves memory leaks, but nothing else.
So you introduce a new feature (gc) at the expense of another
feature (dtors)? Seems pointless to me.
You don't remove destructors; they still work as usual. But the
garbage collector doesn't call them. A garbage collector would
call finalize functions, which are something different. If
a class needs a deterministic destructor (very few do), then
it's finalize function might assert that the destructor has been
called.
The most important aspect of garbage collection isn't that it
prevents memory leaks; it's that it prevents, or at least allows
reliably testing dangling pointers. The memory handling is
convenient in certain contexts as well: it's one less thing the
programmer has to worry about, and it certainly works a lot
better than the usual shared_ptr solutions, but it's not
a silver bullet either (and we've all had to deal with Java
programs which leaked).
Just as RAII prevents memory and resource leaks, RAII also
prevents dangling pointers being an issue.
How?
We're talking about objects with arbitrary lifetimes here.
An experienced (good) C++ programmer will be using RAII in the
form of containers, smart pointers and similar and will be
keeping the use of "naked" pointers to a minimum.
Why? Smart pointers, at least the ones I've seen, don't buy you
anything most of the time.
I cannot remember the last time I had a dangling pointer
issue, it is a rare bug (for me at least).
There is nothing fundamentally wrong with shared_ptr.
Nobody said there was. I use it on a daily basis. It's
a useful tool in certain circumstances. It's not a silver
bullet, however. In some cases, either true garbage collection
or shared_ptr can be used; in such cases, shared_ptr will result
in slightly more work for the programmer, and some cost in
performance, when compared with true garbage collection. In
other cases, shared_ptr doesn't work, and garbage collection
does. And there are cases where shared_ptr works, and garbage
collection doesn't.
This is a typical troll statement I would expect from Mr
Kanze.
It's typical of you to revert to ad hominim, rather than to
discuss real technical issues.
--
James Kanze