Re: Garbage Collection - The Trash Begins To Pile Up
Sean Kelly wrote:
Le Chaud Lapin wrote:
Yes...I am sure that is what went through the managers mind. But there
is illusion and there is truth. The illusion is that C# and GC will
make things better. The truth is that the software was just plain
sloppy. It behooves some of us to maintain the distinction between
illusion and truth.
I don't understand the point you're trying to make here. It seems
you're arguing against C++ having garbage collection by saying that it
will erode confidence in C++ to the point where development shops will
switch to other languages because they have garbage collection?
That might happen too, but what worries me most is the combination of
Dilbert bosses and heapaphiliacs working in unison. Expert C++ coders
notwithstanding, there are people who feel that everything should be on
the heap, or they really do not care. Anyone who has ever had to teach
C++ to Java programmers probably knows how hard it is to get them to
let go of the notion that you do not new() everything in C++, and that
there is merit to not using new for auto objects. There mentality is
that, if you want new object, use new. The "details" are irrelevant,
as they would say.
Now in a large organization, there will inevitably be a clash of
mindsets. [After all, that's what this thread is really about, a clash
of mindsets.] There will be a project where the heapaphiliacs and the
"stackaphiliacs" will have to write code to interface with at some
boundary. There will be an impedance mismatch, just as there was in
COM. The heaphiliacs will demand that we come over to their side, use
GC, and maybe explore a world beyond C++ so that we can "see the
goodness that we are missing." The stackaphiliacs will demand the
opposite say, "We see what you are saying, but those problems you
mention, we simply do not have them." The Dilbert manager will look at
the two sides argue, do a quick head count, and see that the ratio of
heaphiliac to stackaphiliac is 4-1. "Let heapaphilia rule! He shall
say. Give them whatever it is they want. Code is code. Productivity
counts."
Code is code.
And that is how it will begin. After a while, new/delete will
gradually fall out of favor to whatever the GC people use. That whole
argument that we had about the distinction between C++/CLI will become
irrelevant. The code will become increasingly bound to the environment
in which it runs (.NET). If any of the stackaphiliacs complain about
portability, the heapaphiliacs will quickly retort, "But .NET runs
everywhere!"
Notice that I am implying that .NET and GC go hand in hand. I think
they do. I think Microsoft tried to pull this trick with COM, and the
code was so nasty, even the meanderers spat it out (ever write a
Windows Shell Namespace Extension?). Now they are trying the same
thing, this time by actually changing the language. GC is part of the
grand scheme. Before long, they will start killing C++'s type system
with CTS. It perplexes me that no one else notices this, or at least
see hints that there is a possibility that this is the objective. That
they called their column "Pure C++" when it was filled with .NET
code...
Not necessarily, but I agree that it's likely.
Personally, I don't find slippery slope arguments to be terribly
convincing, but I do appreciate your concern. As Greg Herlihy
mentioned however, garbage collection is simply the right choice in
many situations, and eliminating it as an option simply out of fear
that the unschooled masses may use it to tarnish the image of C++ seems
somewhat unreasonable.
For the 50th time. :)
Could some please give me a real example of such a system?
Concurrent programming.
Not the best example. My current research is in distributed
communication, of all kinds, meaning inter-thread, inter-process,
inter-node. I took a look at CP to see what it is about, and, the meat
of what is being offered might have been revolutionary in the early
days of Hoare, but today, much of it is taken for granted. Note that I
am talking about the mechanisms of implementation, not the mathematical
theory behind concurrency. This is more of a problem of how
multi-threaded systems are constructed, not about memory management.
The solution to these problems, is to make your global variables,
protect them with mutexes, and get on with it. Naturally, the more
pleasant the interface is for protection, the greater the mental
relief.
That aside, in the past few years I've been doing a great deal coding
in D and I'll admit I was initially skeptical of GC, but after having
used it for a while I began to realize just how much thought, time, and
design is devoted to memory management in the average C++ program.
Eliminating the need for shared pointers and much of the other baggage
I'm used to in C++ made me more productive, my code cleaner, and the
result was no worse than an equivalent C++ program would have been.
That isn't to say that no thought of memory management is necessary
with GC available, but I think it's a very useful option to have
available.
Well, I have never used a shared pointer in my life. Not one of any
kind. I did once take someone else's where shared pointer was reused,
and refactored it for a different reason, coincidentally eliminating
the need for a shared pointer. I do use an occasional reference count.
And yes, if I ever found myself in a situation where I felt that a
shared pointer was what was really needed, I would certainly use it.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]