Re: Garbage collection in C++
On Nov 17, 8:29 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
James Kanze wrote:
Sometimes I get the impression that garbage collection
actually causes people to write *less* modular and more
imperative programs. GC doesn't really encourage encapsulation
and modularity.
Garbage collection doesn't "encourage" anything.
I tend to disagree.
Sorry, but it's a statement of fact. Garbage collection is just
a tool; a piece of code. It can't encourage or discourage
anything.
At one time, some proponents of garbage collection were trying
to sell it as a silver bullet. Or rather, to sell it as part of
a larger package which was presented as a silver bullet.
Serious programmers, of course, no that silver bullets don't
exist.
Garbage collection encourages writing "irresponsible" code.
How can some code in your machine encourage anything. You're
attributing motives and characterists of a living being to an
inanimate object. (There's a name for this, but I've forgotten
it. But it's frequent among programmers---how often do you hear
a programmer talk about a "bug" which "crept into" his software,
rather than to say "I made an error"?)
By this I mean that since there's no need for objects to have
(memory handling) responsibilities, it easily leads to the
programmer not creating such objects at all, which in turn
leads to a more imperative style of programming, rather than a
more modular style.
Sorry, but I can't follow this at all. Garbage collection
certainly reduces the need for objects dedicated uniquely to
memory management, but how does this relate to whether code is
imperative or not.
For that matter, there are cases where an imperative style is
good. One size doesn't fit all; you need to use the appropriate
technique, among all of those available, to solve each problem.
In practice, garbage collection makes OO (OO in the sense of
using polymorphic objects) easier; polymorphic objects generally
have to be allocated dynamically (supposing the exact type not
known at compile time).
Some people may (and do) argue that this is a good thing,
What is a good thing?
but
I wouldn't be so sure. Granted, you won't leak memory (well,
not permanently at least),
Where to you get this. Garbage collection doesn't mean that you
won't leak memory. The bug list for Java contains a number of
memory leaks.
but your code may suffer from spaghettification just because
you were too lazy to actually write some modules rather than
writing "raw" code.
And no, this doesn't mean *all* programmers using a GC'd
language suffer from this.
Programmers who want to write spaghetti will write spaghetti.
With or without garbage collection. You're not going to claim
that C and C++ encourage readability, I hope. Not with the
preprocessor, pointer arithmetic, and their declaration syntax.
It's just a tool. To be used when appropriate.
Well, if it would be a *choice*, then it wouldn't be so bad.
There are languages, however, where you are force-fed and you
have no choice.
We're talking about C++ here. Where the guiding principle is
that the programmer knows best. And the philosophy is to give
him as many different tools as possible, for him to choose what
it best at any given time.
Other languages have other philosophies. In some cases, what
they were trying to force-feed you wasn't actually a bad idea.
(I'm thinking of Eiffel and programming by contract.) But even
then, experience (mine, anyway) shows that it doesn't pay off in
the long run. As the technology (the tools set) becomes more
widely used, we learn more about it, and change our ideas
somewhat about how to use it.
There are doubtlessly applications where garbage collection
shouldn't be used at all. (There are, in fact, applications
where dynamic memory shouldn't be used at all.) And it
certainly isn't the solution for everything. But the fact that
a technology can be misused has never been an argument against
introducing it into C++, provided that it also has advantages
when correctly used.
--
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