Re: Garbage Collection - The Trash Begins To Pile Up
Joe Seigh wrote:
Greg Herlihy wrote:
In comparison, the typical memory problems of a C++ program are far
more serious: memory leaks, heap corruption, memory "stomping", invalid
output, "crashes" far removed from the site of the error - the variety
of potential C++ memory-management errors is practically infinite, and
uniformly disasterous.
Unless C++ is intended to become a programming language exclusively for
hobbyists and others who write programs for their own enjoyment - then
the C++ language has to evolve from its 80s-era origins if it is to
remain economically competitive as a programming language today.
Fortunately, the C++ committee can read the writing on the wall as well
as anyone: manual memory management is far too error-prone, produces
programs that are far too expensive to debug and maintain, and even
fails to deliver on the type safety guarantees of the language itself,
to be presented as a serious alternative to automated memory
management.
The arguments for garbage collection are a bit contrived and overblown.
There is no silver bullet. GC isn't going to make bad programmers into
good programmers.
Sure it will. By redefining what it takes to be a "good" programmer,
garbarge collection will have precisely such an effect. Namely, today's
"good" programmer needs to master a whole set of skills that tomorrow's
good programmer will have no use for - because garbage collection will
have rendered such knowledge - obsolete. Just as being a "good" driver
used to require the ability to shift gears by hand, the invention of
the automatic transmission made it is possible to be a good driver
without possessing the ability to shift gears by hand. And shifting
gears by hand is no more a requisite driving skill any more than
performing memory management by hand is a requisite programming skill.
In some instances it can make things worse by turning
detectable errors into silent errors. If you think debugging a crash
that occurred much later than the actual error is difficult, try debugging
a bug caused by a silent error which will leave no clues at all as to
where the error occurred. I've debugged multi-threaded crash dumps
including ones where not finding the bug was not an option, where you
were not allowed to tell an enterprise customer that the bug "could
not be reproduced", a cop out which unfortunately way too may software
vendors use today.
You're conflating debugging multi-threaded programs with the
single-threaded garbage-collected model that is the one actually being
discussed. So it's hard to imagine how any observation concerning the
former could be at all relevant or offer any insight at all into the
usefulness of garbage collection to a C++ program as one exists today.
The hardest ones were the silent bugs without
crash dumps. Dumps where data is overwritten by other data? Hey,
that's a clue and much better than no clue at all. Unless you're
one of those software vendors who thinks that customers not being
able to prove that a bug exists is a good thing.
If a bug is not detectable, then by what measure does the bug even
exist?
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]