Re: New C++ garbage collector

From:

James Kanze <james.kanze@gmail.com>

Newsgroups:

comp.lang.c++

Date:

Wed, 27 Oct 2010 03:12:12 -0700 (PDT)

Message-ID:

<687300e7-b654-4795-b09c-ea2e14980ea6@s4g2000yql.googlegroups.com>

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).

--
James Kanze