Previous Table of Contents Next


6.5.9. Rampant Featurism?

A critical issue for the standards committee was how to handle the constant stream of proposals for language changes and extensions. The focus of that effort was the extensions working group of which I was the chairman. It is much easier to accept a proposal than to reject it. You win friends this way and people praise the language for having so many “neat features.” Unfortunately, a language made as a shopping list of features without coherence will die, so there is no way we could accept even most of the features that would be of genuine help to some section of the C++ community.

How did the committee do? Only four major new features were accepted: the “mandated” extensions (exception handling and templates), namespaces, and runtime type information. In addition, about two dozen minor features and clarifications were approved.

As I write this (1998), the chance of any significant additions to the C++ language by the standards committee is zero. Many minor extensions were added, but I think that C++ is now a significantly more powerful, pleasant, and coherent language than it was when the standards process started. See also The Design and Evolution of C++ (Stroustrup, 1994) and The C++ Programming Language, Third Edition (Stroustrup, 1997).

6.6. The Standard Library

To a programmer, the distinction between the language proper and its most fundamental libraries is academic. Essentially, no real code is written in the language itself without the use of libraries, and learning to use the language involves essential library features long before the more advanced and intricate language features are mastered. Consequently, a good standard library is a great asset to a language, and the absence thereof is a liability.

The search for a good set of libraries to include with every C with Classes implementation started even before the completion of the first implementation of the language, and much of the evolution of C++ was driven by a desire to provide better support for library building. Unfortunately, this quest for a good standard library did not yield acceptable results fast enough, and the absence of a large and solid standard library was a liability to C with Classes and C++.

6.6.1. Early Foundation Libraries

The very first real code to be written in C with Classes was the task library (Stroustrup, 1980b), providing Simula-like concurrency for simulation. The first real programs were simulations of network traffic, circuit board layout, and so on, using the task library. The task library was still heavily used in the mid-1990s. The task library was the first of many attempts to provide support for concurrency in C++ (Wilson & Lu, 1996). Many of these attempts were successful, but the extreme diversity of user needs has (at least so far) defeated all attempts to establish a standard model for concurrency for C++. Instead, a variety of system-dependent concurrency facilities are used.

The standard C library was available from C++—without overhead or complication compared with C—from day one. So were all other C libraries. Classical data types such as character strings, range-checked arrays, dynamic arrays, and lists were among the examples used to design C++ and test its early implementations.

The early work with container classes such as list and array were severely hampered by the lack of support for a way of expressing parameterized types. In the absence of proper language support, we had to make do with macros. The best that can be said for the C preprocessor’s macro facilities is that they allowed us to gain experience with parameterized types and support individual and small group use.

Much of the work on early libraries was done in cooperation with Jonathan Shopiro, who in 1983 produced list and string classes that saw wide use within AT&T. These list and string classes are the basis for the classes found in the Standard Components library that was developed in AT&T Bell Labs and later sold by UNIX Systems Laboratories.

The development of these early libraries gave us much valuable experience with C++ and with library design. However, my conclusion at the time was that in the absence of parameterized types, C++ wasn’t capable of supporting a sufficiently good standard library and that we did not understand enough to build a widely acceptable standard library for C++. In retrospect, I was probably right about the technical problems, but I underestimated our ability to provide something (barely) acceptable to users.

The design of these early libraries interacted directly with the design of the language and in particular with the design of the overloading mechanisms.


Previous Table of Contents Next