206 C++ • Your code is more likely to run at maximum efficiency on many dif- ferent platforms in many different configurations. C++ users, alas, are forced to pick up their garbage manually. Many have been brainwashed into thinking that somehow this is more efficient than using something written by experts especially for the platform they use. These same people probably prefer to create disk files by asking for platter, track, and sector numbers instead of by name. It may be more efficient once or twice on a given configuration, but you sure wouldn’t want to use a word processor this way. You don’t even have to take our word for it. Go read The Measured Cost of Conservative Garbage Collection by B. Zorn (Technical Report CU-CS- 573-92, University of Colorado at Boulder) which describes the results of a study comparing performance of programmer-optimized memory manage- ment techniques in C versus using a standard garbage collector. C pro- grammers get significantly worse performance by rolling their own. OK, suppose you’re one of those enlightened C++ programmers who wants a garbage collector. You’re not alone, lots of people agree it’s a good idea, and they try to build one. Oh my, guess what. It turns out that you can’t add garbage collection to C++ and get anything nearly as good as a language that comes with one built-in. For one thing, (surprise!) the objects in C++ are no longer objects when your code is compiled and running. They’re just part of a continuous hexadecimal sludge. There’s no dynamic type infor- mation—no way any garbage collector (or for that matter, a user with a debugger) can point to any random memory location and tell for sure what object is there, what its type is, and whether someone’s using it at the moment. The second thing is that even if you could write a garbage collector that only detected objects some of the time, you’d still be screwed if you tried to reuse code from anyone else who didn’t use your particular system. And since there’s no standard garbage collector for C++, this will most assur- edly happen. Let’s say I write a database with my garbage collector, and you write a window system with yours. When you close one of your win- dows containing one of my database records, your window wouldn’t know how to notify my record that it was no longer being referenced. These objects would just hang around until all available space was filled up—a memory leak, all over again.

The Assembly Language of Object-Oriented Programming 207 Hard to Learn and Built to Stay That Way C++ shares one more important feature with assembly language—it is very difficult to learn and use, and even harder to learn to use well. Date: Mon, 8 Apr 91 11:29:56 PDT From: Daniel Weise daniel@mojave.stanford.edu To: UNIX-HATERS Subject: From their cradle to our grave. One reason why Unix programs are so fragile and unrobust is that C coders are trained from infancy to make them that way. For exam- ple, one of the first complete programs in Stroustrup’s C++ book (the one after the “hello world” program, which, by the way, compiles into a 300K image), is a program that performs inch-to-centimeter and centimeter-to-inch conversion. The user indicates the unit of the input by appending “i” for inches and “c” for centimeters. Here is the outline of the program, written in true Unix and C style: #include stream.h main() { [declarations] cin x ch A design abortion. This reads x, then reads ch. if (ch == 'i') [handle "i" case] else if (ch == 'c') [handle "c" case] else in = cm = 0 That’s right, don’t report an error. Just do something arbitrary. [perform conversion] } Thirteen pages later (page 31), an example is given that implements arrays with indexes that range from n to m, instead of the usual 0 to m. If the programmer gives an invalid index, the program just blithely returns the first element of the array. Unix brain death for- ever!