Previous | Table of Contents | Next |
At about the same time, the part of AT&T that sold C++ commercially wanted a new and improved C++ reference manual and gave Margaret Ellis the task of writing it. It seemed only reasonable to combine the efforts and produce a single, externally reviewed reference manual. It also seemed obvious to me that publishing this manual with some additional information would hasten the acceptance of the new definition and make C++ more widely understood. Thus, the Annotated C++ Reference Manual (Ellis & Stroustrup, 1990) was written to provide a firm basis for the further evolution of C++ (and) to serve as a starting point for the formal standardization of C++.
As Ellis and Stroustrup (1990) pointed out:
The C++ reference manual alone provides a complete definition of C++, but the terse reference manual style leaves many reasonable questions unanswered. Discussions of what is not in the language, why certain features are defined as they are, and how one might implement some particular feature have no place in a reference manual but are nevertheless of interest to most users. Such discussions are presented as annotations and in the commentary sections.
The commentary also helps the reader appreciate the relationships among different parts of the language and emphasizes points and implications that might have been overlooked in the reference manual itself. Examples and comparisons with C also make this book more approachable than the bare reference manual.
After some minor squabbling with the product people, it was agreed that wed write the ARM (as The Annotated C++ Reference Manual came to be popularly called) describing the whole of C++, that is with templates and exception handling, rather than as a manual for the subset implemented by the most recent AT&T release. This was important because it clearly established the language itself as different from any one implementation of it. This principle had been present from the very beginning but needs to be restated often because users and implementors seem to have difficulty remembering it.
I wrote every word of the reference manual proper except the section on the preprocessor that Margaret Ellis adopted from the C Standard. The annotations were jointly written and partly based on my earlier papers (Stroustrup, 1987a, 1987c, 1988a, 1988b).
The reference manual proper of the ARM was reviewed by about a hundred people from two dozen organizations. Most are named in the acknowledgment section of the ARM. In addition, many contributed to the whole of the ARM. The contributions of Brian Kernighan, Andrew Koenig, and Doug McIlroy were specifically noted. The reference manual proper from the ARM was accepted as the basis for the ANSI standardization of C++ in March 1990.
The ARM doesnt attempt to explain the techniques that the language features support. That essential job was left for the second edition of The C++ Programming Language (Stroustrup, 1991).
The initiative toinitiative formal (ANSI) standardization of C++ was taken by HP in conjunction with AT&T, DEC, and IBM. Larry Rosler from HP was important in this initiative. The proposal for ANSI standardization was written by Dmitry Lenkov (1989). Lenkovs proposal cites several reasons for immediate standardization of C++:
The proposal also stressed the need for compatibility with ANSI C. The organizational meeting of the ANSI C++ committee X3J16 took place in December 1989 in Washington, D.C., and was attended by about 40 people, including people who took part in the C standardization, people who by now were old-time C++ programmers, and others. Dmitry Lenkov became its chairman and Jonathan Shopiro its editor.
At the height of its work, the committee had more than 250 members, out of which between 50 and 100 turned up at meetings. The aim of the committee was a draft standard for public review in late 1993 or early 1994 with the hope of an official standard about two years later. A first public review happened in 1995 and a second in 1997. The C++ ISO standard is expected in 1998.
This was an ambitious schedule for the standardization of a general-purpose programming language. To compare, the standardization of C took seven years. The rules for what a standard is and the process by which it is supposed to be produced were repeatedly changed, and different national standards bodies appeared to have quite different interpretations of the ISO rules.
Previous | Table of Contents | Next |