Garbage Collection - The Trash Begins To Pile Up
The purpose of this post is to provide a bit of empirical evidence that
GC is no panacea, and that adding it to C++ might do more harm than
A while ago, I initiated a thread in comp.lang.c++.moderated called
"Garbage Collection - Stop Making Trash!". In that thread, some of us
argued, yet again, that adding garbage collection to C++ would
seriously degrade the integrity of the language. For GC proponents,
our arguments were insufficient, especially those who had deep
experiences with/vested interest in languages like C++/CLI and C#.
Some of these people also failed to see anything wrong with referring
to C++/CLI as "Pure C++" though that has finally been rectified by
renaming the "Pure C++" column, "Netting C++"
What I have noticed over the past 6 months is something peculiar that
one would never expect from the world of GC. Every article related to
..NET or C# that I have seen has had to do with
1. memory management
2. resource cleanup.
For example, the web start page of the Visual Studio 2005 IDE formerly
The beginning of this article states:
"A garbage-collected heap has deep ramifications for destructors, and
that's where we'll start."
"Deep ramifications." That's strange. I thought the purpose of GC was
to relieve the programmer of thinking about deep ramifications.
There have been numerous such articles popping up over the past 6
months. I saw four in the same afternoon two weeks ago. One colleague
had a memory management issue that had something to do with an object
not going away when he wanted it to and asked me to help. As my GC
experience is limited to Lisp, I could not, but I vaguely remember
arriving at the conclusion based on his description of C#'s memory
management model that there was nothing he could do - he was at the
mercy of the GC. Another colleague of mine who abandoned C++ in favor
C# for a year finally came back to the land of deliberate form and
declared, "...well...I still like C# for GUI development, but you get
what you pay for. You have to architect your code right no matter
which language you use. Garbage collection simply makes it more
difficult to find where bad code is being bad."
Another example is the current Visual Studio 2005 IDE start page:
"Uncovering and correcting memory issues in managed applications can be
That sentence says it all. This is written written by a company that
had full control over the garbage collection system of a language it
created. Unlike C++, they had absolute control over the the memory
management system to mold it as they saw fit. Yet, when a programmer
uses the GC model, they might experience the following problems:
* An OutOfMemoryException is thrown.
* The process is using too much memory for no obvious reason that
you can determine.
* It appears that garbage collection is not cleaning up objects
* The managed heap is overly fragmented.
* The application is excessively using the CPU.
All of these symptoms make me wary, but the second (*) is most
impressive... "for no obvious reason that you can determine". The
last word in this sentence, "determine", is closely related to another
word, "determinism", a feature of C++ that is probably the basis for
having never experienced any of these problems in C++.
-Le Chaud Lapin-
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]