Previous Table of Contents Next


The key reason for considering compile-time detection of such problems essential was the observation that C++ is often used for programs executing where no programmer is present. Fundamentally, the notion of static type checking was seen as the best way of providing the strongest guarantees possible for a program rather than merely a way of gaining runtime efficiency.

The “What Is?” paper lists three aspects in which C++ was deficient:

Parameterized types (templates): Ada, Clu, and ML support parameterized types. C++ does not; the syntax used here is simply devised as an illustration. Where needed, parameterized classes are “faked” using macros. Parameterized classes would clearly be extremely useful in C++. They could easily be handled by the compiler, but the current C++ programming environment is not sophisticated enough to support them without significant overhead and inconvenience. There need not be any runtime overheads compared with a type specified directly.

Exception handling: As programs grow, and especially when libraries are used extensively, standards for handling errors (or more generally, “exceptional circumstances”) become important. Ada, Algol68, and Clu each support a standard way of handling exceptions. Unfortunately, C++ does not. Where needed, exceptions are “faked” using pointers to functions, exception objects, error states, and the C library signal and longjmp facilities. In general, this is not satisfactory and fails even to provide a standard framework for error handling.

Multiple inheritance: Given this explanation, it seems obvious that it might be useful to have a class B inherit from two base classes A1 and A2. This is called multiple inheritance. (Stroustrup, 1986c)

All three facilities were linked to the need to provide better (that is, more general, more flexible) libraries. All are now available in C++. Note that adding multiple inheritance and templates was considered as early as 1982 (Stroustrup, 1982).

6.4. C++ Release 2.0: 1985-1988

By mid-1986, the course for C++ was set for all who cared to see. The key design decisions were made. The direction of the future evolution was set with the aim for parameterized types, multiple inheritance, and exception handling. Much experimentation and adjustment based on experience was needed, but the glory days were over. C++ had never been silly putty, but there was now no real possibility for radical change. For good and bad, what was done was done. What was left was an incredible amount of solid work. At this point, C++ had about 2,000 users worldwide.

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 the 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 that first AT&T and then others would start to build compilers and other tools to eventually make Cfront redundant.

Actually, they had already started, but the good plan was soon derailed due to 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 “What Is?” paper. Consequently, a significantly improved and extended library wasn’t part of it.

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, Laura Eaves, Keith Gorlen, Bob Kelley, Brian Kernighan, Andy Koenig, Archie Lachner, Stan Lippman, Larry Mayka, Doug McIlroy, Pat Philip, Dave Prosser, Peggy Quinn, Jerry Schwarz, Roger Scott, Jonathan Shopiro, and Kathy Stark were explicitly acknowledged in Exception Handling for C++ (Stroustrup, 1989b).

Stability of the language definition and its implementation was considered essential. The features of 2.0 were fairly simple modifications of the language based on experience with the 1.* releases. 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.


Previous Table of Contents Next