Re: Garbage collection in C++
On Nov 18, 1:18 pm, Sam <s...@email-scan.com> wrote:
James Kanze writes:
On Nov 18, 12:40 am, Sam <s...@email-scan.com> wrote:
Garbage collection is as useful for C++ as a fifth leg
would be useful to a dog. A dog with five legs might find
some use for the extra one, but most of the time it would
just get in the way.
Another ridiculous analogy, which doesn't relate to anything.
Really? What exactly is so ridiculous about it.
Because it doesn't relate to anything. A dog isn't like a
program, and a fifth leg has nothing to do with garbage
collection. I could just as easily make the analogy of C++
today being a dog with three legs, and garbage collection the
fourth leg. It's a little bit closer to the truth, but not
really much, since dogs and programming languages aren't really
comparable.
A dog does just fine having only four legs. It has no pressing
need for a fifth one. If he had one, he'd probably find some
use for it, but most of the time it'll just get in the way. A
perfect analogy for garbage collection.
I'd say that reducing the number of lines of code I have to
write is a pressing need:-). (Actually, my employers would say
it, since I'm paid on a time passed basis.)
Some people may find some cockamamie "garbage collection
library" useful, but many more do not.
Really. Every one I've talked to who's used the Boehm
collector has found it useful.
You cannot extrapolate such a small sample to the world at
large.
Do you have any other sample to work with. I'm not aware of any
other garbage collector.
Furhtermore -- this is a perfect example:
* Forget about having a proper design. Just start allocating
globs, left and right, and rely on the garbage collector to
clean up after you. This is really a sign of a naive and
inexperienced developer.
Obviously, some one who doesn't know software engineering.
* There's nothing I like more than my application grinding to
a halt, while the garbage collector scans the heap for
pointers.
Obvously, soe one who doesn't know how garbage collection works
today.
Sorry, but I deal in facts, not in myths and wild stories which
have no basis in reality.
Furthermore, there are also people who also find
intermediate code generators useful too. Specifically ones
that swallow some glob of XML, and spew out robo-generate
spaghetti code that does something else XML-related. It's
useful to a small minority, because it allows them to put
their brain in "park", and not bother learning how the
stuff should work. Which leaves them completely helpless if
the end result does not work as expected, since they have
no clue how the spaghetti code works, and what's wrong with
it.
In other words, if I need to tokenize input, I should write
my tokenizer by hand, rather than use some regular
expression based tool. If I want to test my application, I
should write all of the boiler plate code by hand, rather
than using some test generator. If I want to run a program
consisting of machine instructions, I should write the
machine instructions by hand, rather than using some
compiler and linker.
A garbage collector is not a tokenizer and not a compiler.
Both of these tools do what cannot be done efficiently in
other ways.
And how is a garbage collector different. Without these tools,
you can certainly get the job done, but you need to write more
code to do it. Unlike comparing C++ to a dog, this is a valid
analogy.
There's nothing some garbage collector does can do that cannot
be done using proper design, methodology, and programming
practices.
And a bit of extra work. Exactly. There's also nothing that
flex can do that cannot be done using proper design, methodology
and programming practice.
Your argument is that a garbage collector saves you time from
having to do all those pesky things one needs to do, in order
to implement something properly. Well, I suppose, but
sometimes one needs to spend the appropriate amount of time to
do things right. It's an investment well spent.
Hacking out code to solve an already solved problem is not an
investment well spent.
And, yes, there are certain occasions where a hand-built lexer
is better.
Oh, certainly. And there are certain occasions when you won't
want to use garbage collection as well; no one is claiming the
contrary.
There is no such magic wand that one can wave, and make a
bunch of code disappear. Anyone who thinks that is fooling
themselves. Garbage collection-based design results in
larger memory requirements, greater resources, and slower
code.
Than what?
Than proper C++ code that's designed correctly, by someone who
knows what he's doing.
Well, if he really knows what he's doing, he's got the Boehm
collector in his tool box, and will use it when it's
appropriate.
In the cases I've actually seen, garbage collection does
result in increased memory use, sometimes significantly, and
this must be taken into account. (But what is cheaper,
Indeed. The Sun approach. Throw gobs of memory at the problem,
and hope that it goes away.
It's not gobs, and it's not a vain hope. Using garbage
collection reduces the number of lines of code needed to write a
correct application. Even more, it reduces the effort required,
since I don't have to choose which smart pointer to use where.
Now I understand why people were so amazed when I managed to
produce an XML-database gateway, in C++, that consumed less
than a hundred or so of heap, per process instance.
Which doesn't say anything. If you're using a SAX based parser,
there's no need for a big heap, with or without garbage
collection (and this is a perfect example of where garbage
collection does reduce the amount of work). If you're using a
DOM parser, the heap size will depend on input. If the people
who were so amazed were only familiar with DOM, and you used
SAX, you've not proved anything. (For that matter, the fact
that people are amazed generally doesn't prove much. I know a
lot of people who are amazed at Windows.)
Doing these kinds of things efficiently, with an eye towards
minimizing your footprint, is virtually unknown, these days,
now with all these fancy-shmancy garbage collectors and
robocode-spewers making it "convenient" for most not to
actually learn how to do this right.
Apparently, wasting time worrying about things that don't matter
isn't unknown yet. There are times when your memory use
footprint is important, and there are times when it isn't.
Whether my application uses 100KB (without garbage collection)
or 200KB (with) really doesn't interest my boss as much as how
much time I need to produce it.
It's all about engineering trade-offs, and having them
available.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=C3=A9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=C3=A9mard, 78210 St.-Cyr-l'=C3=89cole, France, +33 (0)1 30 23 00 =
34