Bjarne Stroustrup has great paper on his website titled Evolving a language in and for the real world: C++ 1991-2006. It provides fascinating insights on the development of the language, the challenges involved, and discusses interesting design ideas. If you have even a basic understanding of C++, it’s a such a worthwhile read.

The paper is somewhat on the longer side, but is eminently readable. I found certain sections particularly instructive.

Design Principles and Observations

The paper is rich with observations about C++, and enumerates many language design principles. Some particularly resonated with me (referenced sections numbered in square brackets):

• Don’t get involved with a sterile quest for perfection [2].
• What you don’t use, you don’t pay for (zero-overhead) [2].
• Of major languages only C++ provides general, flexible, extensible, and efficient containers implemented in the language itself [2].
• Provide the same support for built-in and user-defined types [4.1.1].
• [It] is perfectly good C++ to use a conservative garbage collection [5.4].
• Most of us [computer programmers] do unusual things some of the time [7.1]
• C++ provides hardly any high-level features that are directly applicable in an application [7.1].
• Unfortunately for C++’s reputation, a good library cannot be seen; it just does his job invisibly to its users [7.3].
• Leave no room for a lower-level language below C++ (except assembler) [7.7].

Exceptions for Flow Control

Many developers believe that using Exceptions for flow control is wrong. Stroustrup does not think so. To quote the paper: Exceptions are typically — and correctly — seen as a control structure: a throw transfers control to some catch clause [5.3.1].

I personally find Exceptions useful for flow control, so raised the issue on Hacker News. The response was immediate and forceful. It seems this remains a controversial point.

Programming is about People

An arc that runs throughout the paper can be summarised by the phrase “Programming Considered as Human Activity“. Stroustrup spends much time discussing the work required by his fellow committee members, and how each personality influences much of the C++ design — much like any software design team.

Stroustrup remarks that “…most groups of programmers — including the C++ committee — are dominated by optimists” [3.3]. Anyone who has worked on a software design team knows this to be true. A new feature always and only will ever take a day or so!

All in all a fascinating paper, be sure to check it out here.