Re: Garbage Collection - The Trash Begins To Pile Up
Carlos Moreno wrote:
Walter Bright wrote:
GC certainly is no panacea. But I've spent 25 years programming in C and
C++, and the worst, nastiest, most time consuming bugs by far have been
related to memory management. Memory management issues also consume a
large part of program design time. These issues don't disappear with GC,
but they are 70-80% reduced with GC.
I have to strongly disagree with these numbers; *memory management*
problems tend to be nasty and hard-to-deal-with. But GC --- and
correct me if I'm wrong --- only addresses memory leaks, which is
by far, but really really really far, the least problematic of the
categories of memory management issues.
It does far more than address memory leaks. It:
1) addresses dangling pointer bugs
2) removes the need to carefully keep track of who 'owns' a chunk of memory
3) (2) often results in a significant simplification of data structures
and algorithms
4) (2) often results in higher speed and less bloat because there's no
longer a need to increment/decrement counts or deal with exception and
thread safety on those counts
5) surprisingly, GC can often lead to a much reduced need to allocate
memory, because much more sharing of data can happen
6) makes it far easier to create reusable library code
Badly managed pointer arithmetic, memory overwrite, buffer overflows,
double-deletion, dereferencing invalid/uninitialized/deleted/NULL
pointers, etc. etc. etc. are the *real* problems regarding memory
management. GC has absolutely nothing to do with any of those.
It does because those problems crop up in code that tries to do explicit
memory management. For example, double deletion bugs are just as common
as failing to delete the memory at all.
Memory leaks are relatively (actually, very) easy to find, and
very easy to fix (provided an absolute minimum of sanity in the
design and the coding);
and, ironically (ironically from the
point of view of wanting to add GC to C++), with C++ it is
extremely easy to *prevent*.
No, they aren't, especially if you deal with 3rd party code. Of course,
if everyone was a top-drawer programmer, there wouldn't be any problems.
But we can't all fly with the eagles.
If it really is all so very easy, why has it taken so long to develop
shared_ptr<>? Are you sure your code has no leaks even in the presence
of exceptions thrown at awkward moments and other threads muck with your
reference counts?
I'll toss out another side effect of C++'s allegedly extremely easy
memory management - the lack of 3rd party libraries relative to those
available for GC'd languages. Reusable libraries for GC languages grow
like weeds, while libraries for C++ seem to require far, far more
engineering before they are generally reusable.
If there's a consistent problem area of programming, then that is a
fertile area for improving the language, since it is a pipe dream to try
and improve the programmer.
I have to agree on this --- but you have to agree also (at least
with the setiment) with Dijkstra's essay "How to Program When you
Can't" (I probably misquoted the title).
But putting that aside, I believe that GC is far from solving the
memory management problems --- I firmly believe that the only
contribution from GC would be increasing/promoting sloppiness
and inviting increasingly lower-skilled programmers into the C++
game. Is that what we want? Do we want to win the popularity
contest? (because if we do, then accepting incomeptent and
unskilled programmers into the game is an absolute necessity)
I have a little difficulty relating that sentiment to your earlier idea
that C++ memory management is "extremely easy."
As for the elitist sentiment you expressed, yes, you *do* want C++ to be
accessible to less than elite programmers. The reason is simple - they
pay the salaries of those who develop C++ compilers, tools, and
libraries. An elite language with too few customers is a dead language.
If --- and I can not stress how much I'm saying this only for
the sake of the argument --- Java is indeed a less error-prone
and more effective/productive programming language, it would
be due to the lack of pointer arithmetic (or rather, in a
sense, the lack of pointers), and not for the GC.
The D programming language has pointers, and a GC (though you can also
do explicit memory management if you want to). The general experience
users have with that is an improvement in productivity and fewer bugs.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]