Previous Table of Contents Next


6.8.2.3. What Should Have Been Added?

As ever, the principle is to add as little as possible. A letter published on behalf of the extensions working group of the C++ standards committee puts it this way (Stroustrup, 1992):

First, let us try to dissuade you from proposing an extension to the C++ language. C++ is already too large and complicated for our taste, and there are millions of lines of C++ code out there that we endeavor not to break. All changes to the language must undergo tremendous consideration. Additions to it are undertaken with great trepidation. Wherever possible, we prefer to see programming techniques and library functions used as alternatives to language extensions.

Many communities of programmers want to see their favorite language construct or library class propagated into C++. Unfortunately, adding useful features from diverse communities could turn C++ into a set of incoherent features. C++ is not perfect, but adding features could easily make it worse instead of better.

Given that, what features have caused trouble by their absence? Or more precisely, what could have been added given our knowledge at the time, given the capabilities of the programmers and systems at the time, and without changing the nature of C++ in a way that I considered undesirable?

I considered many minor features, such as nested functions and the overloading of the . (dot) operator (Stroustrup, 1994). Over the years, C++ acquired enough such little features that minor deletions would probably have benefited the language and its users more than any minor addition. I cannot think of a specific minor feature that would have made a major difference to the majority of C++ programmers without having significant complementary negative side effects.

Of the major features, garbage collection and some support for concurrency featured most prominently in my thinking. As mentioned, I considered requiring garbage collection infeasible and favored optional garbage collection. Similarly, I favored the support of concurrency through machine-specific extensions and libraries. I do harbor a small hope that one day we might develop a close-to-universally acceptable form of concurrency support (see my foreword to Parallel Programming Using C++ [Wilson & Lu, 1996]). However, the support provided by current languages such as Ada95 and Java seems primarily to show how far we still have to go before reaching a sufficiently general and acceptable form of concurrency support.

If I had known how to do so efficiently, I would have added a way of resolving a virtual function call based on the dynamic type of more than one operand. That is, I suspect I would have added a form of multi-methods (Kiczales, des Rivieres, & Bobrow, 1992). However, I never worked out a system for that which satisfied me.

6.8.3. What Was the Biggest Mistake?

To my mind, there really is only one contender for the title of “worst mistake.” Release 1.0 and my first edition (Stroustrup, 1986a) should have been delayed until a larger library, including some simple classes such as singly and doubly linked lists, an associative array class, a range checked array class, and a simple string class, could have been included. The absence of those led to everybody reinventing the wheel and to an unnecessary diversity in the most fundamental classes. However, could I have done that? In a sense, I obviously could. The original plan for my book included three library chapters—one on the stream library, one on the container classes, and one on the task library—so I knew roughly what I wanted. Unfortunately, I was too tired and couldn’t do container classes without some form of templates.

In retrospect, I also regret not having been able to keep working on an implementation to have a proper environment in which to conduct experiments and be able to set a standard for correctness, quality of error messages, quality of code, and so on, that the commercial implementations would have to exceed to be regarded as acceptable. However, the amount of work and the amount of money required to keep such a standards-setting implementation viable were prohibitive. The availability of test suites has not been sufficient to keep the commercial implementations to as high a standard as I would have liked to see. The commercial competition has often focused on programming and execution environments to the detriment of the core language implementations. The standard ought to help, but achieving quality on a large scale is far harder than it appears.

6.8.4. Hopes for the Future

My hope is that C++ may serve its user community well. The language and its standard library are now good enough to be a stable base for tools, environments, and libraries. I expect such supporting facilities to emerge even more rapidly than before. I hope the completeness of the language and the stability of its definition will lead to a new level of stability and quality of implementations. I also expect to see an improvement in compiler speeds and the quality of generated code.

The key is for the C++ community to develop appropriate design and programming techniques and to spread understanding of successful techniques—new and old—much more widely than is currently the case. There are immense gains to be had by using the language more effectively than has been done in most places so far. Standard C++ has the features and the maturity to support techniques that are far more effective than what has been the norm in the industry during the early 1990s. The best has yet to come.


Previous Table of Contents Next