Previous Table of Contents Next


Naturally, standardization of C++ wasn’t 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 meetings—starting 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:

  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 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 some—occasionally heated—debate it was decided that 100% C/C++ compatibility wasn’t an option. Neither was significantly decreasing C compatibility. C++ was a separate language and not a strict superset of ANSI C and couldn’t 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).

6.5.3. C++ 2.1 Feature Overview

The ARM presented a few minor features that were not implemented until 2.1 releases from AT&T and other C++ compiler vendors:

  Nested classes
  Separate overloading of prefix and suffix ++ and --
  volatile (as introduced into C by the ANSI C committee)
  Local static arrays (as introduced into C by the ANSI C committee)

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:

  European character set representation of C++.
  Relaxing the rule for return types for overriding functions.
  Declarations in conditions.
  Overloading based on enumerations.
  User-defined allocation and deallocation operators for arrays.
  Forward declaration of nested classes.
  Mutable.
  More explicit conversion operators (static_cast, reinterpret_cast, and const_cast).
  A Boolean type (bool).
  Optional explicit template instantiation.
  Explicit template argument specification in template function calls.
  Member templates.
  Class templates as template arguments.
  A const static member of integral type can be initialized by a constant-expression within a class declaration.
  Use of extended character sets in identifiers.
  Partial specialization of templates.
  explicit constructors.

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:

  Templates (section 6.5.4)
  Exception handling (section 6.5.5)
  Namespaces (section 6.5.6)
  Runtime type identification (section 6.5.7)

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 programmer’s perspective in The C++ Programming Language, Third Edition (Stroustrup, 1997).


Previous Table of Contents Next