Experiences w/ Garbage Collection and C/C++?

dberger queries: "Java has helped garbage collection enter the mainstream programmer's life - but it's certainly not new or unique to java. There have been (and are) several ways to add garbage collection to C/C++ - the most active seeming to be Hans Boehm's free libgc. I'm curious if any of the Slashdot crowd has used this (or any other) C++ garbage collector in non-trivial commercial applications. If so - what were your experiences? If not, why not? (Before you ask, yes - I know that GC isn't the only difference between C++ and Java, but 'automagic memory management' is certainly part of Java's marketing luster)"

Comments

C++ very expressive indeed

[Latent Heat]

C++ is very expressive indeed, and the example shows that C++ is good at something for which many would consider a scripting language to be required. But like some scripting languages, this C++ code fragment descends into a mix of Egyption hieroglyphics and Hittite cuneiform rather quickly.

So please tell me what

typedef vector::const_iterator Iter;

(or rather vector::const_iterator) is supposed to mean. I suppose vector is a templated class, but how does ::const_iterator come up with a type name -- I thought :: either references a static field or a class member function?

And what is the deal with the sort(,) as a free-standing function? Following OO principles, shouldn't the vector object v know how to sort itself with a call to v.sort()? And what the heck is this const_iterator type anyway that you can do ++ and * on it -- looks an awful lot like a pointer -- oops, I forgot, you can overload ++ and * to make "safe" operations on what are really objects look like "dangerous" pointer operations which the C/C++ community is in custom of using.

In principle, all the stuff done in Java and perhaps in scripting languages could all be done elegantly and expressively in C++ if us mere mortals ever figure out how to use the darned thing. But there is a kind of uniformity to Java (all object variables being GC'd heap references, collection and iterator types working with generic Object's that we cast to what the object is and rely on runtime type checking, don't worry-be happy allocation of these objects where we grab towels from the rack and leave them on the bathroom floor for the hotel maid to pick up) that simply feels more comfortable.

C++ is the music of Bach: elegant, mathematical, intricate, and expressive, but most musicians performing in front of audiences don't understand it and it is played as a dull jumble and mishmash and audiences gaze at Bach stuck at the beginning of a recital as a chore to get through. Java is the music of Mozart: simplified, standardized, predictable, and economical, but musicians of this era understand it and play it with gusto, and audiences love it because it sound so happy and makes them feel uplifted.

Re:your lesson for today

[bmac]

Wow! You even realized it was Kageyama's
book. Man, that is strange, but cool.
BTW, I didn't read the whole book because
I realized that really learning Go was a
full-time occupation and I already have a
few of those :-) But Kage was the best
writer though and I got some good info out
of the few tens of pages I did read.

I hate to keep beating a dead horse, but
my whole point here is the programmer
should know exactly what data is no longer
connected and suitably delete it immediately.
And I know this is lost on the small-focused
but this is indicative of our society -- we
just assume someone else will take care of
"it", whatever it is and no matter the the
long-term costs are far greater than the
short-term cost of taking care of the detail
yourself. We package individual pieces of
candy, and I'm nearly the only person who
finds that completely ridiculous. Sure, it
serves its purpose, but with a more broad-
minded approach to life (and respect for
future generations), we could design systems
for food delivery that used 10% of the current
resources. But, like I said, no one wants
to inconvience themselves to improve the
greater efficiency.

And I'm not gonna flame the Scheme/lisp folks,
as a matter of fact I have recently begun
reading said book because there are no more
interesting CS books (at least at B&N, except
for the DirectX & OpenGL books (and I have
no time for all that fun)), so I figured that
I'd trip down the Lisp lane for awhile.
Anyhow, I don't see any os's written in lisp,
and scant few actual programs. (Autocad, one
of the finest pieces of software in the world,
uses lisp for its scripting, but was written
completely in C). Sure, lisp/scheme is neat
for learning and "concepting" and tail-recursion
is neat, but what gets the job done on a
register-based processor is iterative loops,
and Haskell and Lisp just don't map down
better than C or even C++ (without the STL)
will.

Most programmers do not even realize the power
under the hood of even a Pentium II 400 (which
I use). When you write straight C direct to
win32 api calls, the program response is
*immediate*. The program displays *instantly*
and all functions *fly*. And then I load
the SunOne IDE and it takes friggin one
minute. Someone's missing the point here, and
the person who figures out how to write bullet-
proof C code for straight win32 api is going
to rock some dollars.

Peace & Blessings,
bmac
For the fundamentals of life: www.mihr.com