5. Chronology 1985-1993

Remember, things take time.

– Piet Hein

Post-Release-1.0 chronology — Release 2.0 — 2.0 feature overview — The Annotated C++ Reference Manual and informal standardization — ARM feature overview — ANSI and ISO standardization — standard feature overview.

The reason to depart from the chronological organization is that the actual time order was not important to the final definition of C++. I knew in general terms where the language was going, what problems needed to be addressed, and what kind of features might be needed to address them. However, there was no way I could just sit down and do it all in one major revision of the language. That would have taken too long and would have left me working in a vacuum without essential feedback. Consequently, extensions were developed and added to the language piecemeal. The actual order was of crucial importance to the users at the time and essential for keeping the language coherent at all times. It was, however, not of major importance to the final shape of C++. Presenting the extensions in chronological order would therefore obscure the logical structure of the language.

This chapter presents the work leading to Release 2.0 of Cfront, the work leading to The Annotated C+ + Reference Manual, and the standards effort:

1986-1989:	Release 2.0 rounded off C++ with features such as abstract classes, type-safe linkage, and multiple inheritance, but didn’t add anything radically new.
1988–1990:	The Annotated C+ + Reference Manual added templates and exception handling, and in doing so presented a major challenge to implementers and opened the way to radical changes in the way C++ programs could be written.
1989–1993:	The standards effort added namespaces, run-time type identification, and many minor features to the C++ programmer’s toolset.

In all three cases, significant work was done to make the definition of C++ more precise and to clean up the language by minor changes. From my perspective, it was all one continuing effort.

This was the point where the plan – as originally conceived by Steve Johnson and me – was for a development and support organization to take over the day-to-day work on tools (primarily Cfront), thus freeing me to work on the new features and the libraries that were expected to depend on them. This was also the point where I expected first AT&T and then others to start building compilers and other tools that eventually would make Cfront redundant.

Actually, they had already started, but the good plan was soon derailed due to development management indecisiveness, ineptness, and lack of focus. A project to develop a brand new C++ compiler diverted attention and resources from Cfront maintenance and development. A plan to ship a Release 1.3 in early 1988 completely fell through the cracks. The net effect was that we had to wait until June 1989 for Release 2.0 and that even though 2.0 was significantly better than Release 1.2 in almost all ways, 2.0 did not provide the language features outlined in the “whatis paper” (§3.15) and – partly as a consequence – a significantly improved and extended library wasn’t part of it. Shipping such a library would have been feasible because much of what became the USL† Standard Components library had by then been in internal AT&T production use for some time. However, my wish for direct support for templates still blinded me to alternatives. There was also a misguided belief among some development managers that the library might become both a standard and a significant source of income.

Release 2.0 was the work of a group consisting of Andrew Koenig, Barbara Moo, Stan Lippman, Pat Philip, and me. Barbara coordinated; Pat integrated; Stan and I coded; Andy and I evaluated bug reports and discussed language details; Andy and Barbara did the testing. In all, I implemented all of the new features and something like 80% of the bug fixes for 2.0. In addition, I wrote most of the documentation. As ever, language design issues and the maintenance of the reference manual were my responsibility. Barbara Moo and Stan Lippman became the nucleus of the team that eventually produced Release 2.1 and 3.0.

Many of the people who influenced C with Classes and the original C++ continued to help with the evolution in various ways. Phil Brown, Tom Cargill, Jim Coplien, Steve Dewhurst, Keith Gorlen, Laura Eaves, Bob Kelley, Brian Kernighan, Andy Koenig, Archie Lachner, Stan Lippman, Larry Mayka, Doug McIlroy, Pat Philip, Dave Prosser, Peggy Quinn, Roger Scott, Jerry Schwarz, Jonathan Shopiro, and Kathy Stark were explicitly acknowledged in [Stroustrup, 1989b]. The most active in language discussion during this period were Doug McIlroy, Andy Koenig, Jonathan Shopiro, and I.

Stability of the language definition and its implementation was considered essential [Stroustrup, 1987c]:

“It is emphasized that these language modifications are extensions; C++ has been and will remain a stable language suitable for long term software development.”

And so was C++’s role as a general-purpose language for industrial use [Stroustrup, 1987c]:

“Portability of at least some C++ implementations is a key design goal. Consequently, extensions that would add significantly to the porting time or to the demands on resources for a C++ compiler have been avoided. This ideal of language evolution can be contrasted with plausible alternative directions such as making programming convenient

– at the expense of efficiency or structure;

– for novices at the expense of generality;

– in a specific application area by adding special purpose features to the language;

– by adding language features to increase integration into a specific C++ environment.”

Release 2.0 was a major improvement, but not by providing anything radically new. At the time, I liked to explain that “all of the 2.0 features – including multiple inheritance – are simply removal of restrictions that we had come to see as too constraining; so we removed them.” This was an exaggeration, but a prudent counter to the general tendency to overrate every new feature. From a language design point of view, the most important aspect of Release 2.0 was that it increased the generality of the individual language features and improved their integration into the language. From a user’s point of view, I suspect that the most important aspects of Release 2.0 were the more solid implementation and the improved support.

[1] Multiple inheritance (§12.1)

[2] Type-safe linkage (§11.3)

[3] Better resolution of overloaded functions (§11.2)

[4] Recursive definition of assignment and initialization (§11.4.4)

[5] Better facilities for user-defined memory management (§ 10.2, § 10.4)

[6] Abstract classes (§13.2)

[7] Static member functions (§13.4)

[8] const member functions (§13.3)

[9] protected members (first provided in Release 1.2) (§13.9)

[10] Generalized initializers (§3.11.4)

[11] Base and member initializers (§12.9)

[12] Overloading of operator -> (§11.5.4)

[13] Pointers to members (first provided in Release 1.2) (§13.11)

Most of these extensions and refinements represented experience gained with C++ and couldn’t have been added earlier without more foresight than I possessed. Naturally, integrating these features involved significant work, but it was most unfortunate that this was allowed to take priority over the completion of the language as outlined in the “whatis” paper (§3.15).

Most features enhanced the safety of the language in some way or other. Cfront 2.0 checked the consistency of function types across separate compilation units (type-safe linkage), made the overload resolution rules order-independent, and ensured that more calls were considered ambiguous. The notion of const was made more comprehensive, pointers to members closed a loophole in the type system, and explicit class-specific memory allocation and deallocation operations were provided to make the error-prone “assignment to this” technique (§3.9) redundant.

Of these features, [1], [3], [4], [5], [9], [10], [11], [12], and [13] were in use within Bell Labs at the time of my 1987 USENIX presentation (§7.1.2).

At about the same time, the part of AT&T that sold C++ commercially (USL) wanted a new and improved C++ reference manual and gave one of its employees, 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 help the acceptance of the new definition and make C++ more widely understood. Thus, The Annotated C+ + Reference Manual was written [ARM]:

“to provide a firm basis for the further evolution of C++ ... [and] to serve as a starting point for the formal standardization of C++. ... 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 we’d write the ARM (as The Annotated C+ + Reference Manual is commonly 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 it needs to be restated often because users, implementers, and salesmen seem to have difficulty remembering it.

Of the ARM, I wrote every word of the reference manual proper except the section on the preprocessor (§18) that Margaret Ellis adapted from the ANSI C Standard. The annotations and the commentary sections were jointly written and partly based on my earlier papers [Stroustrup, 1984b, 1987,1988,1988b, 1989b].

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 doesn’t explain the techniques that the language features support: “this book does not attempt to teach C++ programming; it explains what the language is – not how to use it [ARM].” That job was left for the second edition of The C+ + Programming Language [2nd]. Unfortunately, some people discard the advice. The result is often a view of C++ as a mere collection of obscure details and a consequential inability to write elegant and maintainable C++ code; see §7.2.

The major new features presented in the ARM were templates (§15) and exception handling (§16). In addition, the ARM allows people to overload prefix and postfix increment (++) independently (§11.5.3).

To match ANSI C, initialization of local static arrays was allowed.

To match ANSI C, the volatile modifier was introduced to help optimizer implementers. I am not at all sure that the syntactic parallel with const is warranted by semantic similarities. However, I never had strong feelings about volatile and see no reason to try to improve on the ANSI C committee’s decisions in this area.

To sum up, the features presented in the ARM were:

– The 2.0 features (§5.2.1)

– Templates (§15)

– Exceptions (§16)

– Nested classes (§13.5)

– Separate overloading of prefix and suffix ++ and – – (§ 11.5.3)

– volatile

– Local static arrays

The ARM features, excluding exceptions, first became widely available in Release 3.0 of Cfront in September 1991. The complete set of ARM features were first made available in the DEC and IBM C++ compilers in early 1992.

The initiative to formal (ANSI) standardization of C++ was taken by Hewlett-Packard in conjunction with AT&T, DEC, and IBM. Larry Rosier from Hewlett-Packard was important in this initiative. In particular, Larry approached me sometime near the end of 1988, and we had a discussion about the need for formal standardization. The key problem was one of timing. Larry presented the case for urgency on behalf of major users, and I presented the case for delay to allow for further experimentation and experience before standardization. After weighing the multitude of nebulous technical and commercial issues, we agreed that there was a window of about a year during which formal standardization had to begin for us to have a fair chance of success. As I remember it, the first technical meeting of the ANSI committee took place three days before our one-year window opened (March 1990).

The proposal for ANSI standardization was written by Dmitry Lenkov [Len-kov,1989] from Hewlett-Packard. Dmitry’s proposal cites several reasons for immediate standardization of C++:

– C++ is going through a much faster public acceptance than most other languages.

– Delay ... will lead to dialects.

– C++ requires a careful and detailed definition providing full semantics ... for each language feature.

– C++ lacks some important features ... [including] exception handling, aspects of multiple inheritance, features supporting parametric polymorphism, and standard libraries.

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, DC, 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 became its editor.

The first technical meeting was hosted by AT&T in Somerset, New Jersey, in March 1990. AT&T gained that honor not because of any judgement about the company’s contribution to C++, but because we (the members of X3J16 present at the Washington, DC meeting) decided to schedule the first years’ meetings based on the weather. Thus, Microsoft hosted the second meeting in Seattle in July, and Hewlett-Packard hosted the third meeting in Palo Alto in November. This way, we had splendid weather for all three meetings and defused jockeying for status among the corporations represented.

The committee now has more than 250 members out of which something like 70 turn up at meetings. The original 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. This was an ambitious schedule for the standardization of a general-purpose programming language. To compare, the standardization of C took seven years. The current schedule, which I think we have a good chance of meeting, calls for delivery of a draft standard for public review in April 1995†.

Naturally, standardization of C++ isn’t just an American concern. From the start, representatives from other countries attended the ANSI C++ meetings. In Lund, Sweden, in June 1991 the ISO C++ committee WG21 was convened, and the two C++ standards committees decided to hold joint meetings – starting immediately in Lund. Representatives from Canada, Denmark, France, Japan, Sweden, the UK, and USA were present. Notably, the vast majority of these national representatives were actually long-time C++ programmers.

The C++ committee had a difficult charter:

– The definition of the language must be precise and comprehensive.

– C/C++ compatibility had to be addressed.

– Extensions beyond current C++ practice had to be considered.

– Libraries had to be considered.

On top of that, the C++ community was already very diverse and totally unorganized so that the standards committee naturally became an important focal point of the community. In the short run, that is actually the most important role for the committee:

“The C++ committee is a place where compiler writers, tools writers, their friends and representatives can meet and discuss language definition and – as far as commercial rivalries allow – implementation issues. Thus, the C++ committee has already served the C++ community by helping the implementations to become more similar (more “correct”) by providing a forum where issues can be aired. The alternative is a compiler writer alone or together with a few friends finding questions that they see no answer to in the ARM and having to make a guess. Maybe they would mail me – many do – but I can’t cope with every problem that arises and some people do feel that dealing with an individual on such issues isn’t quite proper. Lack of communication inevitably leads to dialects. The committee counteracts such trends. I don’t see how someone who is not directly or indirectly represented on the committee could currently hope to build a tool that was in line with the assumptions made by the major players in the C++ market [Stroustrup, 1992b].”

Standardization isn’t easy. There are people on the committee who are there to preserve status quo, there are people with an idea of status quo that makes them want to turn the clock back several years, there are people who want to make a clean break from the past and design a completely new language, there are people who care only about a single issue, there are people who care only about a single class of systems, there are people whose votes are tied by their employers, there are people who represent only themselves, there are people with a primarily theoretical view of programming and programming languages, there are people who want a standard now! even if it means some details left unresolved, there are people who want nothing short of a perfect definition, there are people who come thinking that C++ is a brand new language with hardly any users, there are people who represent users with many millions of lines of code built over a decade, etc. Under the rules of standardization, we all have to more or less agree. We have to reach “consensus” (usually defined as a large voting majority). These are reasonable rules – and even if they were not, they would still be the national and international rules the committee would have to follow. All the interests are legitimate and having a majority squelch significant minority interests would yield a standard that was useful only to an unnecessarily narrowly defined user community. Thus, every member of the committee must learn to respect points of view that seem alien and learn to compromise. That is actually very much in the spirit of C++.

C compatibility was the first major controversial issue we had to face. After some occasionally heated debate, it was decided that 100% C/C++ compatibility wasn’t an option. Neither was significantly decreasing C compatibility. C++ is a separate language and not a strict superset of ANSI C and can’t be changed to be such a superset without seriously weakening the guarantees provided by the C++ type system – and without breaking millions of lines of C++ code. Similarly, any significant decrease in C compatibility would break code, complicate the creation and maintenance of mixed C and C++ systems, and complicate a transition from C to C++. 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, 1989], is the same conclusion that has been reached over and over again by individuals and groups considering C++ and the direction of its evolution (§3.12). Working out all the details of “As close to C as possible – but no closer” after the independent changes C++ and ANSI C made to the original C manual takes a major part of the standards committee’s effort. Thomas Plum has been a major contributor to this effort.

– Features specified in the ARM (§5.3)

– European character set representation of C++ (§ 6.5.3.1)

– Relaxing rule for return types for overriding functions (§13.7)

– Run-time type identification (§14.2)

– Declarations in conditions (§3.11.5.2)

– Overloading based on enumerations (§ 11.7.1)

– User-defined allocation and deallocation operators for arrays (§10.3)

– Forward declaration of nested classes (§13.5)

– Namespaces (§17)

– Mutable (§13.3.3)

– New casts (§14.3)

– A Boolean type (§11.7.2)

– Explicit template instantiation (§ 15.10.4)

– Explicit template argument specification in template function calls (§15.6.2)

– Member templates (§15.9.3)

– Class templates as template arguments (§15.3.1)

– A const static member of integral type can be initialized by a constant-expression within a class declaration.

– Explicit constructors (§3.6.1)

– Static checking of exception specifications (§16.9).

For more details, see §6.4.2.

† USL started out as an AT&T organization supporting and distributing Unix and related tools; later, it became a separate company called Unix System Laboratories; later it was bought by Novell.

† In July 1994, the committee voted for “CD registration” as the first step of the completion the ISO process is now called. Scheduling a standard isn’t easy. In particular, “details” such as what a standard is and how you must make one aren’t standardized and seems to change every year.