ugh.book

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