Xref: utzoo gnu.g++.help:143 comp.lang.c++:10437 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!apple!uokmax!occrsh!att!dptg!ulysses!andante!alice!bs From: bs@alice.att.com (Bjarne Stroustrup) Newsgroups: gnu.g++.help,comp.lang.c++ Subject: Re: Incompatible changes in C++ Summary: clarification Message-ID: <11635@alice.att.com> Date: 18 Nov 90 15:17:14 GMT References: <9011171750.AA29372@mole.ai.mit.edu> Organization: AT&T Bell Laboratories, Murray Hill NJ Lines: 75 rms@AI.MIT.EDU (Richard Stallman) writes (in reply to a message from Henry Spenser): > Ah, don't you just love language design by committee? Especially > when the committee throws out the "prior art" rule? X3J11 showed > commendable restraint in what they did to C, but there are storm > warnings out for C++... > > This spirit of careless incompatibility can be traced back to > Stroustrup. Didn't he change the behavior of struct and union, > breaking almost all C programs? Make an ambiguous grammar? Before this degenerates further it might be useful to mention a few things. X3J11 did indeed show restraint in what they did to C and I hope X3J16 will show similar restraint. It should be remembered that X3J11 did do a few interesting things to C. Notably it added `const,' prototypes (both adapted from C++), locale in libraries, w_char, the rules for unsigned arithmetic, etc. (in such cases C++ has followed ANSI C). Like C, C++ was at the point of standardization not in a state where simple rubber stamping would make an acceptable standard. In particular, the proposal to standardize C++ (from HP) explicitly mentions the need to add templates and exception handling; both of which have now been voted in. In both cases SOME prior art existed both in C++ and in similar languages. In the case of templates X3J16 found 3 independent implementations and well over half a million lines of code in use. I don't see any signs of a ``spirit of careless incompatibility'' in X3J16 nor could I see how such a thing could originate from me. I am not aware of a having ``change(d) the behavior of struct and union, breaking almost all C programs.'' In fact, nothing C++ does to structs or unions break any C programs. I suspect rms is misinformed. The C++ grammar is indeed not LALR(1). The language extensions that caused that are from 1982/1983. That is, before X3J11 was convened and before an LALR(1) grammar for C was known. That the C++ grammar is not LALR(1) is an inconvenience and X3J16 is looking into what can be done to make the definition of C++ more amenable to formal parser techniques. It should be remembered though that retrofitting a simple LALR(1) grammar would break C++ code and X3J16 would be sensitive to accusations of having broken code. Note that this grammar problem does not imply a C/C++ incompatibility and that it stems directly from the desire from making user-defined types notationally equal to built-in types in C++ (rather than making do with the simple `struct s' and `union u' notation from C). I think that my design choices in this area traded implementor convenience for user convenience. It would have been nice if I had found a way to inconvenience neither group, but I didn't. I would consider it naive to expect a work of the magnitude of C++ to be 100% compatible to C. C++ is a separate language from C. 100% compatibility was not a C++ design aim (remember C didn't even have prototypes when C++ was first put into use), ``no gratuitous incompatibilities'' was the aim. I consider that aim met with more success than most users expect or are aware of. For details see chapter 18 (``Compatibility'') of the ARM or the paper I wrote for ``The C++ Report'' with Andrew Koenig: ``C++ - As close to C but no closer.'' If you want 100% C compatibility use a C compiler. If you are willing to remove anachronisms from your code (typically just adding function prototypes and removing C++ keywords used as identifiers will do the job) you can try C++. If you have a C++ compiler that carefully implements the language as defined by the ARM I suspect you'll be pleasantly surprised with the degree of compatibility. Finally, we have yet to see an example of ``design by committee'' in X3J16. Templates and exception handling were designed by me (helped by Andrew Koenig in the case of exception handling). Naturally, this does not guarantee good design, but it is not design by committee.