Evolving a language in and for the real world: C++ …

1 Evolving a language in and for the real world: C++ 1991-2006 Bjarne StroustrupTexas A&M ~bsAbstractThis paper outlines the history of the C++ programming lan-guage from the early days of its ISO standardization (1991),through the 1998 ISO standard, to the later stages of theC++0x revision of that standard (2006). The emphasis is onthe ideals, constraints, programming techniques, and peoplethat shaped the language , rather than the minutiae of lan-guage features. Among the major themes are the emergenceof generic programming and the STL (the C++ standard li-brary s algorithms and containers). Specific topics includeseparate compilation of templates, exception handling, andsupport for embedded systems programming. During mostof the period covered here, C++ was a mature language withmillions of users. Consequently, this paper discusses varioususes of C++ and the technical and commercial pressures thatprovided the background for its continuing and Subject [History of Com-puting]: systemsGeneral TermsDesign, Programming language , HistoryKeywordsC++, language use, evolution, libraries, stan-dardization, ISO, STL, multi-paradigm programming1.

2 IntroductionIn October 1991, the estimated number of C++ users was400,000 [121]. The corresponding number in October 2004was 3,270,000 [61]. Somewhere in the early 90s C++ left itsinitial decade of exponential growth and settled into a decadeof steady growth. The key efforts over that time were to1. use the language (obviously)2. provide better compilers, tools, and libraries3. keep the language from fragmenting into dialects4. keep the language and its community from stagnating[Copyright notice will appear here once preprint option is removed.]Obviously, the C++ community spent the most time andmoney on thefirst of those items. The ISO C++ standardscommittee tends to focus on the second with some concernfor the third. My main effort was on the third and the ISO committee is the focus for people who aim toimprove the C++ language and standard library. Throughsuch change they (we) hope to improve the state of theart in real-world C++ programming. The work of the C++standards committee is the primary focus of the evolution ofC++ and of this of C++ as a platform for applications, manyhave wondered why after its initial success C++ didn tshed its C heritage to move up the food chain and be-come a truly object-oriented applications programminglanguage with a complete standard library.

3 Any tendenciesin that direction were squelched by a dedication to systemsprogramming, C compatibility, and compatibility with earlyversions of C++ in most of the community associated withthe standards committee. Also, there were never sufficientresources for massive projects in that community. Anotherimportant factor was the vigorous commercial opportunismby the major software and hardware vendors who each sawsupport for application building astheiropportunity to dis-tinguish themselves from their competition and to lock intheir users. Minor players saw things in much the same lightas they aimed to grow and prosper. However, there was nolack of support for the committee s activities within its cho-sen domain. Vendors rely on C++ for their systems and forhighly demanding applications. Therefore, they have pro-vided steady and most valuable support for the standards ef-fort in the form of hosting and more importantly ofkey technical people good and bad, ISO C++ [66] remains a general-purpose programming language with a bias towards systemsprogramming that is a better C supports data abstraction supports object-oriented programming supports generic programmingAn explanation of thefirst three items from a historicalperspective can be found in [120, 121]; the explanation ofEvolving C++ 1991-200612007/5/25 supports generic programming is a major theme of thispaper.

4 Bringing aspects of generic programming into themainstream is most likely C++ s greatest contribution to thesoftware development community during this paper is organized in loose chronological order: 1 Introduction 2 Background: C++ 1979-1991 early history, designcriteria, language features. 3 The C++ world in 1991 the C++ standards process,chronology. 4 Standard library facilities 1991-1998 the C++ stan-dard library with a heavy emphasis on its most impor-tant and innovative component: the STL (containers, al-gorithms, and iterators). 5 language features 1991-1998 focusing on separatecompilation of templates, exception safety, run-time typeinformation and namespaces. 6 Standards maintenance 1997-2003 for stability, noadditions were made to the C++ standard. However, thecommittee wasn t idle. 7C++ in real-world use application areas; applicationsprogramming vs. systems programming; programmingstyles; libraries, Application Binary Interfaces (ABIs),and environments; tools and research; Java, C#, and C;dialects.

5 8C++0x aims, constraints, language features, and li-brary facilities. 9 Retrospective influences and impact; beyond C++.The emphasis is on the early and later years: The early yearsshaped current C++ (C++98). The later ones reflect the re-sponse to experience with C++98 as represented by C++ is impossible to discuss how to express ideas in code with-out code examples. Consequently, code examples are used toillustrate key ideas, techniques, and language facilities. Theexamples are explained to make them accessible to non-C++programmers. However, the focus of the presentation is thepeople, ideas, ideals, techniques, and constraints that shapeC++ rather than on language -technical details. For a descrip-tion of what ISO C++ is today, see [66, 126]. The emphasisis on straightforward questions: What happened? When didit happen? Who were there? What were their reasons? Whatwere the implications of what was done (or not done)?C++ is a living language . The main aim of this paperis to describe its evolution.

6 However, it is also a languagewith a great emphasis on backwards compatibility. The codethat I describe in this paper still compiles and runs , I tend to use the present tense to describe the emphasis on compatibility, the code will probablyalso run as described 15 years from now. Thus, my use ofthe present tense emphasizes an important point about theevolution of C++.2. Background: C++ 1979-1991 The early history of C++ (up until 1991) is covered by myHOPL-II paper [120]. The standard reference for thefirst 15years of C++ is my bookThe Design and Evolution of C++,usually referred to as D&E [121]. It tells the story from thepre-history of C++ until 1994. However, to set the scene forthe next years of C++, here is a brief summary of C++ s ++ was designed to provide Simula s facilities for pro-gram organization together with C s efficiency andflexibilityfor systems programming. It was intended to deliver that toreal projects within half a year of the idea. It the time, I realized neither the modesty nor the pre-posterousness of that goal.

7 The goal was modest in that itdid not involve innovation, and preposterous in both its timescale and its Draconian demands on efficiency andflexibil-ity. While a modest amount of innovation did emerge overthe early years, efficiency andflexibility have been main-tained without compromise. While the goals for C++ havebeen refined, elaborated, and made more explicit over theyears, C++ as used today directly reflects its original in 1979, while in the Computer Science ResearchCenter of Bell Labs, Ifirst designed a dialect of C called Cwith Classes . The work and experience with C with Classesfrom 1979 to 1983 determined the shape of C++. In turn, Cwith Classes was based on my experiences using BCPL andSimula as part of my PhD studies (in distributed systems)in the University of Cambridge, England. For challengingsystems programming tasks I felt the need for a tool withthe following properties: A good tool would have Simula s support for programorganization that is, classes, some form of class hi-erarchies, some form of support for concurrency, andcompile-time checking of a type system based on I saw as support for the process of inventing pro-grams; that is, as support for design rather than just sup-port for implementation.

8 A good tool would produce programs that ran as fast asBCPL programs and share BCPL s ability to combineseparately compiled units into a program. A simple link-age convention is essential for combining units writtenin languages such as C, Algol68, Fortran, BCPL, assem-bler, etc., into a single program and thus not to suffer thehandicap of inherent limitations in a single language . A good tool should allow highly portable implementa-tions. My experience was that the good implementa-tion I needed would typically not be available until nextyear and only on a machine I couldn t afford. This im-plied that a tool must have multiple sources of implemen-tations (no monopoly would be sufficiently responsive tousers of unusual machines and to poor graduate stu-dents), that there should be no complicated run-time sup-port system to port, and that there should be only veryEvolving C++ 1991-200622007/5/25limited integration between the tool and its host operat-ing my early years at Bell Labs, these ideals grew into aset of rules of thumb for the design of C++.

9 General rules:C++ s evolution must be driven by real t get involved in a sterile quest for ++ must be feature must have a reasonably obvious provide a transition ++ is a language , not a complete comprehensive support for each t try to force people to use a specific program-ming style. Design support rules:Support sound design facilities for program what you features must be is more important to allow a useful feature than toprevent every composition of software from separately de-veloped parts. language -technical rules:No implicit violations of the static type as good support for user-defined types as forbuilt-in is order in doubt, pick the variant of a feature that is easiestto matters (often in perverse ways).Preprocessor usage should be eliminated. Low-level programming support rules:Use traditional (dumb) gratuitous incompatibilities with no room for a lower-level language below C++(except assembler).What you don t use, you don t pay for (zero-overheadrule).

10 If in doubt, provide means for manual criteria are explored in detail in Chapter 4 of D&E[121]. C++ as defined at the time of release in 1989strictly fulfilled these criteria; the fundamental tensions inthe effort to design templatesand exception-handling mech-anisms for C++ arose from the need to depart from someaspects of these criteria. I think the most important propertyof these criteria is that they are only loosely connected withspecific programming language features. Rather, they spec-ify constraints on solutions to design this list in 2006, I m struck by two designcriteria (ideals) that are not explicitly stated: There is a direct mapping of C++ language constructs tohardware The standard library is specified and implemented in C++Coming from a C background and being deep in the devel-opment of the C++98 standard ( ), these points (at thetime, and earlier) seemed so obvious that I often failed toemphasize them. Other languages, such as Lisp, Smalltalk,Python, Ruby, Java, and C#, do not share these ideals.