Re: Garbage Collection - The Trash Begins To Pile Up
Mirek Fidler wrote:
James Kanze wrote:
it (but it won't make it any worse). On the other hand, by
reducing the effort needed by good programmers to produce good
code, it will allow more time for them to replace the bad code
Well, what I am afraid that GC will in fact force good programmers to
produce bad code, without even knowing it.
How can something you're not required to use force you to do
anything? I've used garbage collection, both in C++ and in
Java, and I think that the code I wrote was good.
Again: bad programmers will write bad code, and good programmers
will write good code. The only significant difference is the
amount of effort it will take them to do it; garbage collection
offers good programmers an additional tool, to use WHEN
APPROPRIATE.
Take for example that famous Walter's "blisteringly faster" "word
count" D benchmark. While we might disagree with design of that
language, I guess nobody here ever disputed Walter's ability to write a
good code.
I've never seen any code he's written, so I can't say:-). (I've
used code he's written, however. And I can't say that the
quality of the Zortech compiler particularly inspired me. Of
course, "quality" and "C++ compiler" were pratically oxymoric
back then, but it was still far behind CFront, and only a little
better than g++.)
Still, if you run his example to count words on 100 x 1MB text files,
it will need 100MB to do that (at least if there is at least one unique
word in each file). While GC does not have memory leaks by definition,
I guess without GC you would mark such code as leaking the memory.
GC doesn't absolutely prevent memory leaks; I don't know where
you got that idea from. A number of bug reports for Swing
concerned memory leaks. As to Walter's code: if the
requirements limit the number and size of the files, and the
memory is available, it's not a bug. In my own code, I
generally don't accept such limitations, however.
The funny part is that this behavior is not at all transparently
visible... With deterministic approach, if there is a memory leak, I
simply get an error at program exit.
Memory leaks aren't usually a serious problem if the program
exits:-). Most of my programs don't.
But that's beside the point. Garbage collection isn't, IMHO,
about preventing memory leaks per se; your code shouldn't leak
memory, even without garbage collection. It's about reducing
the programmer effort necessary to prevent them, or more
generally, the programmer effort necessary to impose a
deterministic lifetime on objects which don't need it (but do
need a lifetime which cannot be modeled on scope).
With GC, consuming more memory than necessary is always left
undetected.
Nonsense. Typically, garbage collection will use more memory
than the equivalent code with manual management. Which means
that if you're leaking, the machine will start thrashing even
sooner. (And of course, if you're still getting memory, and not
thrashing, there's no problem:-).)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]