210 C++ Michael Worst of all, the biggest problem with C++, for those who use it on a daily basis, is that even with a restricted subset, the language is hard to read and hard to understand. It is difficult to take another programmer’s C++ code, look at it, and quickly figure out what it means. The language shows no taste. It’s an ugly mess. C++ is a language that wants to consider itself object-oriented without accepting any of the real responsibilities of object orientation. C++ assumes that anyone sophisticated enough to want gar- bage collection, dynamic loading, or other similar features is sophisticated enough to implement them for themselves and has the time to do so and debug the implementation. The real power of C++’s operator overloading is that it lets you turn rela- tively straightforward code into a mess that can rival the worst APL, ADA, or FORTH code you might ever run across. Every C++ programmer can create their own dialect, which can be a complete obscurity to every other C++ programmer. But—hey—with C++, even the standard dialects are private ones. Abstract What? You might think C++’s syntax is the worst part, but that’s only when you first start learning it. Once you get underway writing a major project in C++, you begin to realize that C++ is fundamentally crippled in the area of abstraction. As any computer science text will tell you, this is the principle source of leverage for sensible design. Complexity arises from interactions among the various parts of your sys- tem. If you have a 100,000–line program, and any line of code may depend on some detail appearing in any other line of code, you have to watch out for 10,000,000,000 possible interactions. Abstraction is the art of con- straining these interactions by channeling them through a few well-docu- mented interfaces. A chunk of code that implements some functionality is supposed to be hidden behind a wall of modularity. Classes, the whole point of C++, are actually implemented in a way that defies modularity. They expose the internals to such an extent that the users of a class are intimately dependent on the implementation details of that

Abstract What? 211 class. In most cases, changing a class forces a recompile of all code that could possibly reference it. This typically brings work to a standstill while entire systems must be recompiled. Your software is no longer “soft” and malleable it’s more like quick-setting cement. Of course, you have to put half of your code in the header files, just to declare your classes to the rest of the world. Well, of course, the public/pri- vate distinctions provided by a class declaration are worthless since the “private” information is in the headers and is therefore public information. Once there, you’re loathe to change them, thereby forcing a dreaded recompile. Programmers start to go to extraordinary lengths to add or change functionality through twisted mechanisms that avoid changing the headers. They may run into some of the other protection mechanisms, but since there are so many ways to bypass them, these are mere speedbumps to someone in a hurry to violate protocol. Cast everything as void* and presto, no more annoying type checking. Many other languages offer thoughtfully engineered mechanisms for dif- ferent kinds of abstraction. C++ offers some of these, but misses many important kinds. The kinds it does offer are confused and hard to under- stand. Have you ever met anyone who actually likes using templates? The result is that the way many kinds of concepts are expressed depends on the context in which they appear and how they are used. Many important con- cepts cannot be expressed in a simple way at all nor, once expressed, can they be given a name that allows them subsequently to be invoked directly. For example, a namespace is a common way of preventing one set of names appropriate to one part of your code from colliding with another set of names from another part. A program for a clothing manufacturer may have a class called Button, and it may be linked with a user interface tool- kit with another class called Button. With namespaces, this is no problem, since the rules for the usage and meaning of both concepts are clear and easy to keep straight. Not so in C++. There’s no way to be sure you haven’t taken a name used somewhere else in your program, with possibly catastrophic consequences. Your only hope is to garble up your code with nonsensical prefixes like ZjxButton and hope nobody else does the same. Date: Fri, 18 Mar 94 10:52:58 PST From: Scott L. Burson gyro@zeta-soft.com Subject: preprocessor