Re: Garbage Collection - The Trash Begins To Pile Up
Greg Herlihy wrote:
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.
This analogy is not entirely appropriate. We they gave us automatic
transmissions, they took away the clutch. With C++, we will end up
with both the automatic transmission and the clutch. [On an amusing
note, I took some of my French friends on a road trip to Canada. One
of them had never been in a car with an automatic transmission, and
tried to down-shift at 40mph. Thank God for dog teeth.]
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.
Well, he mentions multi-threading as the context, but the same thing
could happen without multi-threading. In fact, it is happening now.
You really should read the links I put in the OP. It's in plain
English: GC has issues that need to be addressed.
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?
Again, read the bullet points that Microsoft wrote in their article
about how GC causes strange problems. I will rewrite them here:
Reprint:
Another example is the current Visual Studio 2005 IDE start page:
http://msdn.microsoft.com/msdnmag/issues/06/11/CLRInsideOut/default.aspx
"Uncovering and correcting memory issues in managed applications can be
difficult. "
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
fast enough.
* The managed heap is overly fragmented.
* The application is excessively using the CPU.
"memory issues" is a euphemism for "bugs".
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]