Syntax Syrup of Ipecac 209 Date: Sun, 21 May 89 18:02:14 PDT From: tiemann (Michael Tiemann) To: sdm@cs.brown.edu Cc: UNIX-HATERS Subject: C++ Comments Date: 21 May 89 23:59:37 GMT From: sdm@cs.brown.edu (Scott Meyers) Newsgroups: comp.lang.c++ Organization: Brown University Dept. of Computer Science Consider the following C++ source line: //********************** How should this be treated by the C++ compiler? The GNU g++ compiler treats this as a comment-to-EOL followed by a bunch of asterisks, but the AT&T compiler treats it as a slash followed by an open-comment delimiter. I want the former interpretation, and I can’t find anything in Stroustrup’s book that indicates that any other interpretation is to be expected. Actually, compiling -E quickly shows that the culprit is the preprocessor, so my questions are: 1. Is this a bug in the AT&T preprocessor? If not, why not? If so, will it be fixed in 2.0, or are we stuck with it? 2. Is it a bug in the GNU preprocessor? If so, why? Scott Meyers sdm@cs.brown.edu There is an ancient rule for lexing UNIX that the token that should be accepted be the longest one acceptable. Thus ‘foo’ is not parsed as three identifiers, ‘f,’ ‘o,’ and ‘o,’ but as one, namely, ‘foo.’ See how useful this rule is in the following program (and what a judicious choice ‘/*’ was for delimiting comments): double qdiv (p, q) double *p, *q { return *p/*q } So why is the same rule not being applied in the case of C++? Sim- ple. It’s a bug.

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