Re: Garbage Collection - The Trash Begins To Pile Up
Carlos Moreno wrote:
Walter Bright wrote:
It does far more than address memory leaks. It:
1) addresses dangling pointer bugs
How?? The way I see it, it only changes the behaviour in the presence
of accessing a dangling pointer --- worse: it is just hiding the
symptom of the real problem (the eral problem being that there *is*
a dangling pointer and someone is using it when they shouldn't).
You can't have a dangling pointer with GC. You'll never be accessing an
invalid object.
IMHO, a better solution than GC is to make the behaviour of
dereferencing invalid pointers perfectly defined --- it really is
the infamous undefined behaviour the real cause of all the mess
that is attributed to memory management in C++. If dereferencing
an invalid pointer (*any form* of an invalid pointer --- deleted,
uninitialized, NULL, etc.) threw an exception, things would be
much, much better.
That's a nice idea, but it is unimplementable with current CPUs (if you
want any sort of efficiency).
Again, we do not want to promote sloppiness from the prorgammers;
hiding the symptoms of a problem and make it silently have no
effect (or seem to have to effect) does not help; it promotes
and fascilitates sloppiness.
I don't agree at all. Does automatic register allocation facilitate
sloppiness?
2) removes the need to carefully keep track of who 'owns' a chunk of
memory
The compiler is very careful in keeping track of who owns what;
and we already have the tools to leverage all this compiler power
to automate memory management and relieve the programmer from the
big nightmare.
Yes, such a tool is called GC <g>.
3) (2) often results in a significant simplification of data structures
and algorithms
I disagree. Well, or rather, I could claim that it is far more
often that the "automatable" model of C++ memory management results
in a simplification of data structures and algorithms.
You could so claim, but I have never seen a data structure that is
simpler for that reason. On the other hand, I can report that I can
dispense with reference counting members and functions, and often copy
constructors and destructors, and even assignment overloading, when I
switch to GC.
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
Higher speed and less bloat??? It depends on how you define higher
speed and how you define bloat
higher speed - runs in less time
less bloat - smaller code and data size
--- I could claim that GC is an
unnecessary bloating of my apps; and as for speed; if I unpredictably
have to wait who-knows-how-long because the garbage collector decided
that it needed/wanted to act, I do not think that would qualify as
"good speed" --- or, you could put it this way: you want speed? I
need responsiveness.
There are many straightforward ways to deal with the pause issue with
GC, that problem was addressed at least 10 years ago.
Speed, we have it almost for free nowadays
with ever increasingly powerful hardware.
And we correspondingly demand ever more from them.
5) surprisingly, GC can often lead to a much reduced need to allocate
memory, because much more sharing of data can happen
Ok, good point. But again, in C++ you can already achieve the exact
same level of data sharing, with pointers and without worrying about
all the messy details of manual memory management (shared_ptr when
you need it, custom data structures when you must)
shared_ptr<> is a messy detail itself <g>. As for the "exact same level
of data sharing", consider the following D programming language code:
char[] string = "hello world";
char[] foo = string[3..6];
foo now refers to "lo " in the string array (a copy is not created).
Supporting arbitrary interior references is pretty hard to do with
manual memory management, but it's almost a no-brainer with GC. If you
do manage it with C++, you certainly are going to be dealing with messy
details of manual memory management, as neither shared_ptr<> nor any of
the other standard library components can do it.
6) makes it far easier to create reusable library code
Maybe. Only, and with much stress, *maybe* ...
I think the evidence suggests it is with much less stress than with C++.
I would really be willing to bet one month of my salary that none
of any applications that any of my students (in that course) has
ever created has any memory leaks, or any memory-management problem
whatsoever; and we're talking about a lot of them (and as I said,
most of them are far below "elitesque" level). Actually, wait,
maybe some of them do have problems --- I'm now remembering that
a few of those students had had prior experience programming in
C; yep, I would bet another month of my salary that if there
are any programs with memory management issues, is one created
by some of those students with prior experience in C (well, or
in C++, which they most likely had learned from the likes of
Deitel & Deitel, which means that they had really learned C)
Student homework projects must be completable in a few hours, hence they
tend to be trivial. I don't think it's reasonable to assume the problems
they encounter are comparable to professional projects.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]