Previous | Table of Contents | Next |
Naturally, standardization of C++ wasnt just an American (ANSI) concern. From the start, representatives from other countries attended the ANSI C++ meetings. And in Lund, Sweden, in June 1991, the ISO C++ committee WG21 was convened and the two C++ standards committees decided to hold joint meetingsstarting immediately in Lund. Represen-tatives from Canada, Denmark, France, Japan, Sweden, the UK, and the U.S. were present. Notably, the vast majority of these national representatives were actually long-time C++ programmers. The C++ committee had a difficult mission:
On top of that, the C++ community was very diverse and totally unorganized so that the standards committee naturally became an important focal point of that community. In the short run, that is the most important role for the committee.
C compatibility was the first major controversial issue we had to face. After someoccasionally heateddebate it was decided that 100% C/C++ compatibility wasnt an option. Neither was significantly decreasing C compatibility. C++ was a separate language and not a strict superset of ANSI C and couldnt be changed to be such a superset without breaking the C++ type system and without breaking millions of lines of C++ code. This decision, often referred to as As Close to C as Possible but no closer after a paper written by Andrew Koenig and me (Koenig & Stroustrup, 1989a), is the same one that has been reached over and over again by individuals and groups considering C++ and the direction of its evolution (section 6.3.4).
The ARM presented a few minor features that were not implemented until 2.1 releases from AT&T and other C++ compiler vendors:
The most obvious of these were nested classes. I was strongly encouraged to revert to the original definition of nested class scopes by comments from external reviewers of the reference manual. I also despaired over ever getting the scope rules of C++ coherent while the C rule was in place (section 6.3.4). Having classes be proper scopes for their members has proven invaluable in library design.
The main impetus to allow people to overload prefix and postfix increment (++) independently came from people who wanted smart pointers that behaved exactly like ordinary pointers except for some added work done behind the scenes. The specific problem that convinced me came from Brian Kernighan.
During the standards process, many more minor features were added:
I deem a feature minor if its use primarily affects the clarity of individual statements and localized pieces of code. The design of C++ was centered on major features. I consider a language feature major if it affects the way we think about programming and the way we organize our code. The ARM and the standardization process introduced four major features:
Both minor and major features are described from a historical and design perspective in The Design and Evolution of C++ (Stroustrup, 1994) and from a programmers perspective in The C++ Programming Language, Third Edition (Stroustrup, 1997).
Previous | Table of Contents | Next |