Casey
recently wrote about the woes of garbage collection. Here’s my
unsolicited take on the subject.

The big plus for GC is that it enables better software
engineering. A bit of global information — whether or not an object
is potentially in use — is handled globally, and no particular of
user module is responsible for its deallocation. This makes it much
simpler to write APIs; simply pass around objects as you like and the
system handles it.

Nothing is free, of course. You can usually expect to pay a speed
penalty with GC (though finding how large of one may be complicated).
The presence of GC changes the programming system in other ways as
well, for instance it ordinarily necessitates the presence of weak
references.

And, no conversation of GC would be complete without mentioning
that certain kinds of memory leaks will still persist. If you
continue to have a live reference to an object which will not be used
in the future, it won’t be collected. Explicit deallocation proponent
often erroneously point to this as a kind of GC failure, either
explicitly, or secondarily, as in “if you must explicitly null a
pointer, you might as well introduce a free() in the same
spot”. There are (at least) two points here: first, that in a GC
environment this is a local problem which can be fixed locally, and
second, the important point of GC is not that it reclaims memory, but
that it does not reclaim live memory.

That said, it is pretty easy to write C++ classes that basically
automate memory management. And, with a little planning in one’s
program, it is easy to avoid memory leaks altogether.

For gcjx, I wrote a simple “owning pointer” class that does
reference counting (you can find better ones in Boost). I’ve run into one or two
memory management bugs, mostly due to little design flaws in my API.
So, the situation in C++ really needn’t be that bad.

But then, gcjx is a fairly self-contained program, and the data
structures it builds are largely trees (with sole ownership). I
think the situation gets worse for explicit allocation when you start
looking at very large programs with modules over which you have
little control.

The ease of writing C++ wrapper classes is a minus, though, not a
plus, when it comes to this topic. Suppose you use a collection of
several libraries. Either you will end up using plain pointers and
missing out on the benefits of C++, or you’ll have to find ways to mix
and match various ownership approaches, potentially a fragile affair.
This is one of the big benefits of GC as I see it: not the technology
per se, but the API unification it implies across libraries.

Of course, the real reason I like GC is that I’m just lazy and it
makes the hacking go quicker.