在现实世界中发展语言：C++1991-2006(待续)
Evolving a language in and for the real world: C++ 1991-2006
Bjarne Stroustrup Texas A&M University www.research.att.com/~bs
Abstract
This paper outlines the history of the C++ programming language from the early days of its ISO standardization (1991),
through the 1998 ISO standard, to the later stages of the C++0x revision of that standard (2006).
本文概述了C++编程语言自ISO标准化初期（1991年）以来的历史，
通过1998年的ISO标准，到该标准的 C++0x 修订版（2006）的后期阶段。
The emphasis is on the ideals, constraints, programming techniques, and people
that shaped the language, rather than the minutiae of language features. Among the major themes are the emergence
of generic programming and the STL (the C++ standard library’s algorithms and containers).
重点是理想、约束、编程技术和人员 ，这塑造了语言，而不是语言特征的细节。其中的主要主题是泛型编程和STL（C++标准库的算法和容器）。
Specific topics include separate compilation of templates, exception handling, and support for embedded systems programming.
具体主题包括模板的单独编译、异常处理和对嵌入式系统编程的支持。
During most of the period covered here, C++ was a mature language with millions of users.
在本文所涵盖的大部分时间里，C++是一种成熟的语言，拥有数百万用户。
Consequently, this paper discusses various uses of C++ and the technical and commercial pressures that provided the background for its continuing evolution.
因此，本文讨论了C++的各种用途以及为其持续发展提供背景的技术和商业压力
Categories and Subject Descriptors K.2 [History of Computing]:
类别和主题描述符K.2[计算历史]：
systems General Terms Design, Programming Language, History Keywords C++, language use, evolution, libraries, standardization, ISO, STL, multi-paradigm programming
系统通用术语设计、编程语言、历史关键字C++、语言使用、进化、库、标准化、ISO、STL、多范式编程
1. Introduction (介绍)
In October 1991, the estimated number of C++ users was
400,000 [121]. The corresponding number in October 2004
was 3,270,000 [61]. Somewhere in the early ’90s C++ left its
initial decade of exponential growth and settled into a decade
of steady growth. The key efforts over that time were to
1991年10月，C++用户的估计数量为400,000 [121]. 2004年10月的相应数字为3270000【61】。在90年代早期的某个地方，C++留下了指数增长的最初十年，进入十年
稳定增长。这段时间的主要努力是
1. use the language (obviously) 使用语言（显然）
2. provide better compilers, tools, and libraries 提供更好的编译器、工具和库
3. keep the language from fragmenting into dialects 防止语言分裂成方言
4. keep the language and its community from stagnating 防止语言及其社区停滞不前
Obviously, the C++ community spent the most time and money on the first of those items.
显然，C++社区在第一个项目上花费的时间和金钱最多。
The ISO C++ standards committee tends to focus on the second with some concern for the third.
ISO C++标准委员会倾向于关注第二个标准，而对第三个标准则有所关注。
My main effort was on the third and the fourth. The ISO committee is the focus for people who aim to improve the C++ language and standard library.
我的主要努力是在第三次和第四次。ISO委员会是致力于改进C++语言和标准库的人们关注的焦点。
Through such change they (we) hope to improve the state of the art in real-world C++ programming.
通过这样的改变，他们（我们）希望提高现实世界C++编程的技术水平。
The work of the C++ standards committee is the primary focus of the evolution of C++ and of this paper.
C++标准委员会的工作是C++发展和本文的主要重点。
Thinking of C++ as a platform for applications, many have wondered why
许多人认为C++是一个应用程序平台，他们想知道为什么
— after its initial success — C++ didn’t shed its C heritage to “move up the food chain” and become a “truly object-oriented” applications programming
language with a “complete” standard library.
在其最初的成功之后，C++并没有放弃它的C传统，而是“向食物链上游”，成为“真正面向对象”的应用程序编程具有“完整”标准库的语言
Any tendencies in that direction were squelched by a dedication to systems programming, C compatibility, and compatibility with early
versions of C++ in most of the community associated with the standards committee.
由于致力于系统编程、C兼容性以及与早期与标准委员会相关的大多数社区中的C++版本
Also, there were never sufficient resources for massive projects in that community. Another important factor was the vigorous commercial opportunism
此外，该社区从未有足够的资源用于大规模项目。另一个重要因素是激烈的商业机会主义
by the major software and hardware vendors who each saw support for application building as their opportunity to distinguish themselves from their competition and to lock in
their users. Minor players saw things in much the same light as they aimed to grow and prosper. However, there was no lack of support for the committee’s activities within its chosen domain. Vendors rely on C++ for their systems and for highly demanding applications.
主要的软件和硬件供应商都认为支持应用程序构建是他们从竞争对手中脱颖而出并锁定自己的机会
他们的用户。小玩家对事情的看法与他们追求成长和繁荣的目标大致相同。然而，委员会在其选定领域内的活动不乏支持。供应商的系统和高要求的应用程序都依赖于C++。
Therefore, they have provided steady and most valuable support for the standards effort in the form of hosting and — more importantly — of
key technical people attending.
因此，他们以托管的形式为标准工作提供了稳定和最有价值的支持，更重要的是关键技术人员参加。
For good and bad, ISO C++ [66] remains a generalpurpose programming language with a bias towards systems programming that
不管好坏，ISO C++[66]仍然是一种通用编程语言，偏向于系统编程
• is a better C 是更好的C
• supports data abstraction 支持数据抽象
• supports object-oriented programming 支持面向对象编程
• supports generic programming 支持泛型编程
An explanation of the first three items from a historical perspective can be found in [120, 121]; 从历史角度对前三项的解释见【120121】；
the explanation of “supports generic programming” is a major theme of this paper.
“支持泛型编程”的解释是本文的一个主要主题。
Bringing aspects of generic programming into the mainstream is most likely C++’s greatest contribution to the software development community during this period.
将泛型编程的各个方面纳入主流很可能是C++在此期间对软件开发社区的最大贡献。
The paper is organized in loose chronological order:
论文按松散的时间顺序组织：
§1 Introduction
§2 Background: C++ 1979-1991 — early history, design criteria, language features.
背景：C++1979-1991-早期历史、设计标准、语言特性。
§3 The C++ world in 1991 — the C++ standards process, chronology.
1991年的C++世界——C++标准过程，年表。
§4 Standard library facilities 1991-1998 — the C++ standard library with a heavy emphasis on its most important and innovative component: the STL (containers, algorithms, and iterators).
标准库设施1991-1998-C++标准库，重点强调其最重要和创新的组件：STL（容器、算法和迭代器）。
§5 Language features 1991-1998 — focusing on separate compilation of templates, exception safety, run-time type information and namespaces.
1991-1998年的语言特性-重点关注模板、异常安全、运行时类型信息和名称空间的单独编译。
§6 Standards maintenance 1997-2003 — for stability, no additions were made to the C++ standard. However, the committee wasn’t idle.
1997-2003年标准维护-为了稳定性，未对C++标准进行任何添加。然而，委员会并非无所事事。
§7 C++ in real-world use — application areas; applications programming vs. systems programming; programming styles; libraries, Application Binary Interfaces (ABIs), and environments; tools and research; Java, C#, and C; dialects.
C++在现实世界中的应用领域；应用程序编程与系统编程；编程风格；库、应用程序二进制接口（ABI）和环境；工具和研究；Java、C#和C；方言。
§8 C++0x — aims, constraints, language features, and library facilities.
C++0x-目标、约束、语言特性和库设施。
§9 Retrospective — influences and impact; beyond C++.
回顾-影响和影响；超越C++
The emphasis is on the early and later years: The early years
重点是早期和后期：早期
shaped current C++ (C++98). The later ones reflect the response to experience with C++98 as represented by C++0x.
塑造了当前的C++（C++98）。后者反映了对以C++0x为代表的C++98体验的响应。
It is impossible to discuss how to express ideas in code without code examples. Consequently, code examples are used to illustrate key ideas, techniques, and language facilities.
如果没有代码示例，就不可能讨论如何在代码中表达想法。因此，代码示例用于说明关键思想、技术和语言设施。
The examples are explained to make them accessible to non-C++ programmers.
解释这些示例是为了让非C++程序员能够访问它们。
However, the focus of the presentation is the people, ideas, ideals, techniques, and constraints that shape C++ rather than on language-technical details.
然而，演示的重点是塑造C++的人、思想、理想、技术和约束，而不是语言技术细节。
For a description of what ISO C++ is today, see [66, 126].
有关当今ISO C++的描述，请参见[66126]。
The emphasis is on straightforward questions: What happened? When did it happen? Who were there? What were their reasons? What were the implications of what was done (or not done)?
重点是直截了当的问题：发生了什么？什么时候发生的？谁在那里？他们的理由是什么？所做（或未做）的事情有何影响？
C++ is a living language. The main aim of this paper is to describe its evolution. However, it is also a language with a great emphasis on backwards compatibility.
C++是一种活的语言。本文的主要目的是描述其演变。然而，它也是一种非常强调向后兼容性的语言。
The code that I describe in this paper still compiles and runs today.
我在本文中描述的代码至今仍在编译和运行。
Consequently, I tend to use the present tense to describe it. Given the emphasis on compatibility, the code will probably also run as described 15 years from now. Thus, my use of the present tense emphasizes an important point about the evolution of C++.
因此，我倾向于用现在时来描述它。考虑到对兼容性的强调，代码可能也会在15年后按所述运行。因此，我使用现在时强调了C++发展的一个重要方面。
2. Background: C++ 1979-1991
The early history of C++ (up until 1991) is covered by my HOPL-II paper [120].
我的HOPL-II论文介绍了C++的早期历史（直到1991年）。
The standard reference for the first 15 years of C++ is my book 《The Design and Evolution of C++》, usually referred to as D&E [121].
我的书《C++的设计和发展》（通常称为D&E）是 C++ 前15年的标准参考资料。
It tells the story from the pre-history of C++ until 1994. However, to set the scene for the next years of C++, here is a brief summary of C++’s early history.
它讲述了从C++出现之前到1994年的故事。然而，为了为C++的未来几年奠定基础，这里简要总结了C++的早期历史。
C++ was designed to provide Simula’s facilities for program organization together with C’s efficiency and flexibility for systems programming.
It was intended to deliver that to real projects within half a year of the idea. It succeeded.
C++旨在为Simula的程序组织提供便利，并为系统编程提供C的效率和灵活性。其目的是将其交付给真正的项目在半年内的想法。它成功了。
At the time, I realized neither the modesty nor the preposterousness of that goal.
当时，我既没有意识到这个目标的谦虚，也没有意识到它的荒谬。
The goal was modest in that it did not involve innovation, and preposterous in both its time scale and its Draconian demands on efficiency and flexibility.
目标是适度的，因为它不涉及创新，而且无论是时间规模还是对效率和灵活性的苛刻要求都是荒谬的。
While a modest amount of innovation did emerge over the early years, efficiency and flexibility have been maintained without compromise.
虽然早年确实出现了少量创新，但效率和灵活性一直保持不变。
While the goals for C++ have been refined, elaborated, and made more explicit over the years, C++ as used today directly reflects its original aims.
多年来，C++的目标已经被细化、细化并变得更加明确，而今天使用的C++直接反映了其最初的目标。
Starting in 1979, while in the Computer Science Research Center of Bell Labs, I first designed a dialect of C called “C with Classes”.
从1979年开始，在贝尔实验室的计算机科学研究中心，我第一次设计了一种称为“C with Classes”的C方言。
The work and experience with C with Classes from 1979 to 1983 determined the shape of C++.
从1979年到1983年，C的工作和经验决定了C++的形态。
In turn, C with Classes was based on my experiences using BCPL and Simula as part of my PhD studies (in distributed systems)
反过来，C with Class是基于我在博士研究（分布式系统）中使用BCPL和Simula的经验
in the University of Cambridge, England. For challenging systems programming tasks I felt the need for a “tool” with the following properties:
在英国剑桥大学。对于具有挑战性的系统编程任务，我觉得需要一个具有以下特性的“工具”：
• A good tool would have Simula’s support for program organization – that is, classes, some form of class hierarchies, some form of support for concurrency, and
compile-time checking of a type system based on classes.
一个好的工具应该具有Simula对程序组织的支持，即类、某种形式的类层次结构、某种形式的并发支持，以及基于类的类型系统编译时检查。
This I saw as support for the process of inventing programs; that is, as support for design rather than just support for implementation.
我认为这是对发明程序过程的支持；也就是说，作为对设计的支持，而不仅仅是对实现的支持。
• A good tool would produce programs that ran as fast as BCPL programs and share BCPL’s ability to combine separately compiled units into a program.
一个好的工具可以生成运行速度与BCPL程序一样快的程序，并共享BCPL将单独编译的单元组合到一个程序中的能力。
A simple linkage convention is essential for combining units written in languages such as C, Algol68, Fortran, BCPL, assembler, etc., into a single program and thus not to suffer the
handicap of inherent limitations in a single language.
一个简单的链接约定对于将用C、Algol68、Fortran、BCPL、汇编等语言编写的单元组合到一个程序中是必不可少的，这样就不会受到单一语言固有限制的障碍。
• A good tool should allow highly portable implementations. My experience was that the “good” implementation I needed would typically not be available until “next
year” and only on a machine I couldn’t afford.
一个好的工具应该允许高度可移植的实现。我的经验是，我所需要的“良好”实现通常在“下一步”之前不可用只有在我买不起的机器上。
This implied that a tool must have multiple sources of implementations (no monopoly would be sufficiently responsive to users of “unusual” machines and to poor graduate students), that there should be no complicated run-time support system to port, and that there should be only very limited integration between the tool and its host operating system.
这意味着一个工具必须有多个实现源（没有垄断可以充分响应“不寻常”机器的用户和差劲的研究生），不应该有复杂的运行时支持系统来移植，工具与其主机操作系统之间的集成应该非常有限。
During my early years at Bell Labs, these ideals grew into a set of “rules of thumb” for the design of C++.
在我在贝尔实验室的早年，这些理念发展成为一套C++设计的“经验法则”。
• General rules: (通用规则)
C++’s evolution must be driven by real problems. C++的发展必须由实际问题驱动。
Don’t get involved in a sterile quest for perfection. 不要陷入对完美的毫无结果的追求。
C++ must be useful now. C++现在一定很有用了。
Every feature must have a reasonably obvious implementation. 每个特性都必须有一个相当明显的实现。
Always provide a transition path. 始终提供过渡路径。
C++ is a language, not a complete system. C++是一种语言，不是一个完整的系统。
Provide comprehensive support for each supported style. 为每种受支持的样式提供全面支持。
Don’t try to force people to use a specific programming style. 不要试图强迫人们使用特定的编程风格。
• Design support rules(设计支持规则):
Support sound design notions. 支持合理的设计理念。
Provide facilities for program organization. 为项目组织提供设施。
Say what you mean. 说出你的意思。
All features must be affordable. 所有功能都必须价格合理。
It is more important to allow a useful feature than to prevent every misuse. 允许一个有用的特性比防止每一次滥用更重要
Support composition of software from separately developed parts. 支持从单独开发的部分组成软件。
• Language-technical rules:(语言技术规则)
No implicit violations of the static type system. 没有对静态类型系统的隐式冲突。
Provide as good support for user-defined types as for built-in types. 为用户定义的类型提供与内置类型一样好的支持
Locality is good. 位置很好
Avoid order dependencies.避免订单依赖关系。
If in doubt, pick the variant of a feature that is easiest to teach. 如果有疑问，请选择最容易设定的功能变体。
Syntax matters (often in perverse ways).语法很重要（通常以反常的方式）。
Preprocessor usage should be eliminated. 应消除预处理器的使用。
• Low-level programming support rules:(低级编程支持规则)：
Use traditional (dumb) linkers. 使用传统（哑）链接器。
No gratuitous incompatibilities with C. 与C没有无缘无故的不兼容。
Leave no room for a lower-level language below C++ (except assembler).
What you don’t use, you don’t pay for (zero-overhead rule). 你不用的东西，你不用付费（零开销规则）。
If in doubt, provide means for manual control. 如有疑问，提供手动控制方法。
These criteria are explored in detail in Chapter 4 of D&E [121]. D&E第4章对这些标准进行了详细探讨【121】
C++ as defined at the time of release 2.0 in 1989 strictly fulfilled these criteria; the fundamental tensions in the effort to design templates and exception-handling mechanisms for C++ arose from the need to depart from some aspects of these criteria.
1989年2.0版时定义的C++严格满足这些标准；在为C++设计模板和异常处理机制的过程中，由于需要偏离这些标准的某些方面，出现了根本性的紧张。
I think the most important property of these criteria is that they are only loosely connected with specific programming language features. Rather, they specify constraints on solutions to design problems.
我认为这些标准最重要的特性是，它们只与特定的编程语言特性松散地联系在一起。相反，它们指定了设计问题解决方案的约束条件。
Reviewing this list in 2006, I’m struck by two design criteria (ideals) that are not explicitly stated:
2006年回顾这份清单时，我被两个没有明确说明的设计标准（理想）所震惊：
• There is a direct mapping of C++ language constructs to hardware C++语言结构直接映射到硬件
• The standard library is specified and implemented in C++ Coming from a C background and being deep in the development of the C++98 standard (§3.1), these points (at the
time, and earlier) seemed so obvious that I often failed to emphasize them.
标准库是在C++中指定和实现的，它来自C的背景，并且深入于C++98标准（§3.1）的开发时间和更早的时间）似乎太明显了，以至于我常常没有强调它们。
Other languages, such as Lisp, Smalltalk, Python, Ruby, Java, and C#, do not share these ideals.
其他语言，如Lisp、Smalltalk、Python、Ruby、Java和C#，都不具备这些理念。
Most languages that provide abstraction mechanisms still have to provide the most useful data structures, such as strings, lists, trees, associative arrays, vectors, matrices, and sets, as builtin facilities, relying on other languages (such as assembler, C, and C++) for their implementation.
大多数提供抽象机制的语言仍然必须提供最有用的数据结构，如字符串、列表、树、关联数组、向量、矩阵和集合，作为内置设施，依赖其他语言（如汇编、C和C++）来实现。
Of major languages, only C++ provides general, flexible, extensible, and efficient containers implemented in the language itself.
在主要语言中，只有C++提供了在语言本身中实现的通用、灵活、可扩展和高效的容器。
To a large extent, these ideals came from C. C has those two properties, but not the abstraction mechanisms needed to define nontrivial new types.
在很大程度上，这些理想来自C。C有这两个属性，但没有定义非平凡新类型所需的抽象机制。
The C++ ideal – from day one of C with Classes (§2.1)
C++的理想——从C和类的第一天开始（§2.1）
– was that the language should allow optimal implementation of arbitrary data structures and operations on them.
语言应该允许对任意数据结构和操作进行优化实现。
This constrained the design of abstraction mechanisms in many useful ways [121] and led to new and interesting implementation techniques (for example, see §4.1).
这在许多有用的方面限制了抽象机制的设计[121]，并导致了新的有趣的实现技术（例如，参见§4.1）。
In turn, this ideal would have been unattainable without the “direct mapping of C++ language constructs to hardware” criterion.
反过来，如果没有“C++语言构造到硬件的直接映射”标准，这一理想将无法实现。
The key idea (from C) was that the operators directly reflected hardware operations (arithmetic and logical) and that access to memory was what the hardware directly offered (pointers and arrays).
关键思想（来自C）是操作符直接反映硬件操作（算术和逻辑），而对内存的访问是硬件直接提供的（指针和阵列）。
The combination of these two ideals is also what makes C++ effective for embedded systems programming [131] (§6.1).
这两种理念的结合也是C++对嵌入式系统编程有效的原因【131】（§6.1）。
2.1 The Birth of C with Classes (C with Classes的诞生)
The work on what eventually became C++ started with an attempt to analyze the UNIX kernel to determine to what
extent it could be distributed over a network of computers connected by a local area network.
关于最终成为C++的工作始于试图分析UNIX内核以确定它可以分布在由局域网连接的计算机网络上的范围。
This work started in April of 1979 in the Computing Science Research Center of Bell Laboratories in Murray Hill, New Jersey.
这项工作于1979年4月在新泽西州默里山贝尔实验室的计算科学研究中心开始。
Two subproblems soon emerged: 两个子问题很快出现：
how to analyze the network traffic that would result from the kernel distribution and how to modularize the kernel.
如何分析内核分布导致的网络流量，以及如何对内核进行模块化。
Both required a way to express the module structure of a complex system and the communication pattern of the modules.
两者都需要一种方法来表达复杂系统的模块结构和模块的通信模式。
This was exactly the kind of problem that I had become determined never to attack again without proper tools.
这正是我决心在没有适当工具的情况下永远不再处理的那种问题。
Consequently, I set about developing a proper tool according to the criteria I had formed in Cambridge.
因此，我开始根据我在剑桥形成的标准开发一个合适的工具。
In October of 1979, I had the initial version of a preprocessor, called Cpre, that added Simula-like classes to C.
1979年10月，我有了一个名为Cpre的预处理器的初始版本，它向C中添加了类似Simula的类。
By March of 1980, this pre-processor had been refined to the point where it supported one real project and several experiments.
到1980年3月，这个预处理器已经改进到支持一个实际项目和几个实验的程度。
My records show the pre-processor in use on 16 systems by then. The first key C++ library, called “the task system”, supported a coroutine style of programming [108, 115].
我的记录显示，到那时，预处理器已在16个系统上使用。第一个关键的C++库，称为“任务系统”，支持协同编程风格[108115]。
It was crucial to the usefulness of “C with Classes,” as the language accepted by the pre-processor was called, in most early projects.
在大多数早期项目中，这对于“C with Classes”的有用性至关重要，正如前处理器所接受的语言所称。
During the April to October period the transition from thinking about a “tool” to thinking about a “language” had occurred, but C with Classes was still thought of primarily as an extension to C for expressing modularity and concurrency.
在4月至10月期间，从考虑“工具”到考虑“语言”的转变已经发生，但带类的C仍然主要被认为是C的扩展，用于表示模块性和并发性。
A crucial decision had been made, though. Even though support of concurrency and Simula-style simulations was a primary aim of C with Classes, the language contained no primitives for expressing concurrency; rather, a combination of inheritance (class hierarchies) and the ability to define class member functions with special meanings recognized by the pre-processor was used to write the library that supported the desired styles of concurrency.
不过，已经做出了一个至关重要的决定。尽管支持并发和Simula风格的模拟是C with Class的主要目标，但该语言不包含表示并发的原语；相反，使用继承（类层次结构）和定义具有预处理器识别的特殊含义的类成员函数的能力来编写支持所需并发样式的库。
Please note that “styles” is plural. I considered it crucial — as I still do — that more than one notion of concurrency should be expressible in the language.
请注意，“styles”是复数形式。我认为，在语言中应该表达不止一个并发概念，这一点至关重要，我现在仍然这样认为。
Thus, the language provided general mechanisms for organizing programs rather than support for specific application areas.
因此，该语言提供了组织程序的一般机制，而不是对特定应用领域的支持。
This was what made C with Classes and later C++ a general-purpose language rather than a C variant with extensions to support specialized applications.
这就是为什么 C with Classes 以及后来的C++成为一种通用语言，而不是一种具有支持专门应用程序的扩展的C变体。
Later, the choice between providing support for specialized applications or general abstraction mechanisms has come up repeatedly.
后来，在为专用应用程序提供支持还是提供一般抽象机制之间，人们反复提出了选择。
Each time, the decision has been to improve the abstraction mechanisms. 2.2 Feature Overview The earliest features included • classes • derived classes • constructors and destructors •
每一次，决策都是为了改进抽象机制。2.2特征概述最早的特征包括•类•派生类•构造函数和析构函数•
public/private access control • type checking and implicit conversion of function arguments. In 1981, a few more features were added based on perceived need: • inline functions
• default arguments • overloading of the assignment operator.
公共/私有访问控制•函数参数的类型检查和隐式转换。1981年，根据感知的需求，又增加了一些功能：•内联函数• 默认参数•赋值运算符重载。
Since a pre-processor was used for the implementation of C with Classes, only new features, that is features not present in C, needed to be described and the full power of C was directly available to users. Both of these aspects were appreciated at the time.
由于使用预处理器来实现带有类的C，因此只需要描述新特性，即C中不存在的特性，并且用户可以直接使用C的全部功能。这两个方面在当时都受到了赞赏。
In particular, having C as a subset dramatically reduced the support and documentation work needed. C with Classes was still seen as a dialect of C.
特别是，将C作为子集大大减少了所需的支持和文档工作。带类的C仍然被视为C的一种方言。
Furthermore, classes were referred to as “An Abstract Data Type Facility for the C Language” [108].
此外，类被称为“C语言的抽象数据类型工具”[108]。
Support for objectoriented programming was not claimed until the provision of virtual functions in C++ in 1983 [110].
直到1983年在C++中提供虚拟函数，才声称支持面向对象编程[110]。
A common question about “C with Classes” and later about C++ was “Why use C? Why didn’t you build on, say, Pascal?” One version of my answer can be found in [114]:
关于“C with Classes”以及后来关于C++的一个常见问题是“ 为什么使用C？ 为什么不建立在Pascal 上？” 我的答案的一个版本可以在【114】中找到：
C is clearly not the cleanest language ever designed nor the easiest to use, so why do so many people use it?
C显然不是有史以来设计的最干净的语言，也不是最容易使用的语言，那么为什么这么多人使用它呢？
• C is flexible: It is possible to apply C to most every application area, and to use most every programming technique with C. The language has no inherent limitations that preclude particular kinds of programs from being written.
C是灵活的：可以将C应用于几乎所有的应用领域，并将几乎所有的编程技术与C一起使用。这种语言没有固有的限制，不允许编写特定类型的程序。
• C is efficient: The semantics of C are ‘low level’; that is, the fundamental concepts of C mirror the fundamental concepts of a traditional computer. Consequently, it is relatively easy for a compiler and/or a programmer to efficiently utilize hardware resources for a C program.
C是有效的：C的语义是“低级的”；也就是说，C的基本概念反映了传统计算机的基本概念。因此，编译器和/或程序员相对容易有效地利用C程序的硬件资源。
• C is available: Given a computer, whether the tiniest micro or the largest super-computer, the chance is that there is an acceptable-quality C compiler available and that that C compiler supports an acceptably complete and standard C language and library. There are also libraries and support tools available, so that a programmer rarely needs to design a new system from scratch.
C可用：给定一台计算机，无论是最小的微型计算机还是最大的超级计算机，都有可能有一个质量可以接受的C编译器可用，并且该C编译器支持一个可以接受的完整和标准的C语言和库。还有可用的库和支持工具，因此程序员很少需要从头开始设计新系统。
• C is portable: A C program is not automatically portable from one machine (and operating system) to another nor is such a port necessarily easy to do. It is, however, usually possible and the level of difficulty is such that porting even major pieces of software with inherent machine dependences is typically technically and economically feasible.
C是可移植的：C程序不能自动从一台机器（和操作系统）移植到另一台机器，这样的端口也不一定容易实现。然而，这通常是可能的，而且难度很大，因此移植具有内在机器依赖性的主要软件在技术和经济上都是可行的。
Compared with these ‘first-order’ advantages, the ‘second-order’ drawbacks like the curious C declarator syntax and the lack of safety of some language constructs become less important. Pascal was considered a toy language [78], so it seemed easier and safer to add type checking to C than to add the features considered necessary for systems programming to Pascal.
与这些“一阶”优点相比，“二阶”缺点，如奇怪的C声明程序语法和某些语言构造缺乏安全性，变得不那么重要。Pascal被认为是一种玩具语言，因此将类型检查添加到C似乎比将系统编程所需的功能添加到Pascal更容易、更安全。
At the time, I had a positive dread of making mistakes of the sort where the designer, out of misguided paternalism or plain ignorance, makes the language unusable for real work in important areas.
当时，我非常害怕犯这样的错误，设计师出于误导的家长作风或无知，使语言无法用于重要领域的实际工作。
The ten years that followed clearly showed that choosing C as a base left me in the mainstream of systems programming where I intended to be.
接下来的十年清楚地表明，选择C作为基础使我在系统编程的主流中成为我想要的。
The cost in language complexity has been considerable, but (just barely) manageable. The problem of maintaining compatibility with an evolving C language and standard library is a serious one to this day (see §7.6).
语言复杂性的代价相当大，但（几乎）难以控制。与不断发展的C语言和标准库保持兼容性的问题至今仍是一个严重的问题（见§7.6）。
In addition to C and Simula, I considered Modula-2, Ada, Smalltalk, Mesa, and Clu as sources for ideas for C++ [111], so there was no shortage of inspiration.
除了C和Simula之外，我还将Modula-2、Ada、Smalltalk、Mesa和Clu视为C++[111]思想的来源，因此不乏灵感。
2.3 Work Environment 工作环境
C with Classes was designed and implemented by me as a research project in the Computing Science Research Center of Bell Labs.
C with Classes是我在贝尔实验室计算科学研究中心设计和实现的一个研究项目。
This center provided a possibly unique environment for such work. When I joined in 1979, I was basically told to “do something interesting,” given suitable computer resources, encouraged to talk to interesting and competent people, and given a year before having to formally present my work for evaluation.
该中心为此类工作提供了一个可能独特的环境。1979年加入时，我基本上被告知要“做一些有趣的事情”，并得到适当的计算机资源，鼓励我与有趣和有能力的人交谈，还有一年的时间，我才不得不正式提出我的工作进行评估。
There was a cultural bias against “grand projects” requiring many people, against “grand plans” like untested paper designs for others to implement, and against a class distinction between designers and implementers.
有一种文化偏见，反对需要许多人参与的“宏大项目”，反对像未经测试的纸上设计这样的“宏大计划”供他人实施，反对设计师和实施者之间的阶级区分。
If you liked such things, Bell Labs and other organizations had many places where you could indulge such preferences.
如果你喜欢这样的东西，贝尔实验室和其他组织有很多地方可以让你享受这样的偏好。
However, in the Computing Science Research Center it was almost a requirement that you — if you were not into theory — personally implemented something embodying your ideas and found users who could benefit from what you built.
然而，在计算科学研究中心，如果你不懂理论，你几乎需要亲自实现一些体现你想法的东西，并找到可以从你构建的东西中受益的用户。
The environment was very supportive for such work and the Labs provided a large pool of people with ideas and problems to challenge and test anything built.
环境非常支持这些工作，实验室为大量的人提供了想法和问题，以挑战和测试任何构建的东西。
Thus I could write in [114]: “There never was a C++ paper design; design, documentation, and implementation went on simultaneously. Naturally,
the C++ front-end is written in C++.
因此，我可以在[114]中写道：“从来没有C++的纸上设计；设计、文档和实现同时进行。很自然，C++前端是用C++编写的。
There never was a “C++ project” either, or a “C++ design committee”.
也从来没有“C++项目”或“C++设计委员会”。
Throughout, C++ evolved, and continues to evolve, to cope with problems encountered by users, and through discussions between the author and his friends and colleagues”.
自始至终，C++不断发展，以应对用户遇到的问题，并通过作者与朋友和同事之间的讨论”。
2.4 From C with Classes to C++(C with Classes 到 C++)
During 1982, it became clear to me that C with Classes was a “medium success” and would remain so until it died.
1982年，我清楚地认识到，C with Class是一个“中等成功”，并将一直保持到它消亡。
The success of C with Classes was, I think, a simple consequence of meeting its design aim: C with Classes helped organize a large class of programs significantly better than C.
我认为，C with class的成功是实现其设计目标的一个简单结果：C with class帮助组织了一个比C更好的大型课程。
Crucially, this was achieved without the loss of run-time efficiency and without requiring unacceptable cultural changes in development organizations.
至关重要的是，这是在不损失运行时效率的情况下实现的，也不需要在开发组织中进行不可接受的文化变革。
The factors limiting its success were partly the limited set of new facilities offered over C and partly the pre-processor technology used to implement C with Classes.
限制其成功的因素部分是通过C提供的新工具集有限，部分是用于通过类实现C的预处理器技术。
C with Classes simply didn’t provide support for people who were willing to invest significant effort to reap matching benefits:
C with Classes根本没有为那些愿意投入大量精力来获得相应利益的人提供支持：
C with Classes was an important step in the right direction, but only one small step.
C with Classes 是朝着正确方向迈出的重要一步，但只是一小步。
As a result of this analysis, I began designing a cleaned-up and extended successor to C with Classes and implementing it using traditional compiler technology.
作为这一分析的结果，我开始用类设计一个经过清理和扩展的C后继程序，并使用传统的编译器技术实现它。
In the move from C with Classes to C++, the type checking was generally improved in ways that are possible only using a proper compiler front-end with full understanding of all syntax and semantics.
在从C with Classes迁移到C++的过程中，类型检查得到了普遍的改进，只有在充分理解所有语法和语义的情况下使用适当的编译器前端才能实现。
This addressed a major problem with C with Classes. In addition,
这解决了C with Classes 的一个主要问题。此外
• virtual functions 虚函数
• function name and operator overloading
• references 引用
• constants (const)
• many minor facilities were added. To many, virtual functions were the major addition, as they enable object-oriented programming.
增加了许多小型设施。对许多人来说，虚函数是主要的补充，因为它们支持面向对象编程。
I had been unable to convince my colleagues of their utility, but saw them as essential for the support of a key programming style (“paradigm”).
我无法说服我的同事们相信它们的实用性，但我认为它们对于支持关键编程风格（“范式”）至关重要。
After a couple of years of use, release 2.0 was a major release providing a significantly expanded set of features, such as
经过几年的使用，2.0版是一个主要版本，提供了一组显著扩展的功能，如
• type-safe linkage,
• abstract classes
• multiple inheritance.
Most of these extensions and refinements represented experience gained with C++ and could not have been added earlier without more foresight than I possessed.
大多数这些扩展和改进代表了使用C++所获得的经验，如果没有比我更具远见的话，就不可能更早地添加这些扩展和改进。
2.5 Chronology(纪年表)
The chronology of the early years can be summarized:早年的年表可以总结如下：
1979 Work on C with Classes starts; first C with Classes use
1979年 工作在C with Classes上；第一次使用C with Classes
1983 1st C++ implementation in use
1983年第一个C++实现被使用
1984 C++ named
1984 C++ 被命名
1985 Cfront Release 1.0 (first commercial release); The C++ Programming Language (TC++PL) [112]
1985 Cfront Release 1.0（第一个商业版本）；C++编程语言（TC++PL）[112]
1986 1st commercial Cfront PC port (Cfront 1.1, Glockenspiel)
1987 1st GNU C++ release
1987年GNU C++第1版
1988 1st Oregon Software C++ release; 1st Zortech C++ release;
1988年俄勒冈州第一个软件C++版本；第一个Zortech C++版本
1989 Cfront Release 2.0; The Annotated C++ Reference Manual [35]; ANSI C++ committee (J16) founded (Washington, D.C.)
1989 Cfront 2.0版；带注释的C++参考手册[35]；ANSI C++委员会（J16）成立（华盛顿特区）
Evolving C++ 1991-2006 5 2007/5/25 (进化C++1991-2006 5 2007/5/25)
1990 1st ANSI X3J16 technical meeting (Somerset, New Jersey); templates accepted (Seattle, WA); exceptions accepted (Palo Alto, CA); 1st Borland C++ release
1991 1st ISO WG21 meeting (Lund, Sweden); Cfront Release 3.0 (including templates); The C++ Programming Language (2nd edition) [118] On average, the number of C++ users doubled every 7.5
months from 1 in October 1979 to 400,000 in October of 1991 [121]. It is of course very hard to count users, but during the early years I had contacts with everyone who shipped
compilers, libraries, books, etc., so I’m pretty confident of these numbers. They are also consistent with later numbers from IDC [61].
3. The C++ World in 1991(1991年的C++世界)
In 1991, the second edition of my The C++ Programming Language [118] was published to complement the 1989 language definition The Annotated C++ Reference Manual
(“the ARM”) [35].
1991年，我的《C++编程语言》（the C++Programming Language）[118]第二版出版，以补充1989年的语言定义《带注释的C++参考手册》 （“手臂”）【35】。
Those two books set the standard for C++ implementation and to some extent for programming techniques for years to come.
这两本书为C++实现以及未来几年的编程技术制定了标准。
Thus, 1991 can be seen as the end of C++’s preparations for entry into the mainstream.
因此，1991年可以看作是C++进入主流的准备工作的结束。
From then on, consolidation was a major issue. That year, there were five C++ compilers to choose from (AT&T, Borland, GNU, Oregon, and Zortech) and three more were to appear in 1992 (IBM, DEC, and Microsoft).
从那时起，整合是一个重大问题。那一年，有五个C++编译器可供选择（AT&T、Borland、GNU、Oregon和Zortech），还有三个将于1992年出现（IBM、DEC和Microsoft）。
The October 1991 AT&T release 3.0 of Cfront (my original C++ compiler [121]) was the first to support templates.
The DEC and IBM compilers both implemented templates and exceptions, but Microsoft’s did not, thus seriously setting back efforts to encourage programmers to use a more modern style.
DEC和IBM编译器都实现了模板和异常，但微软没有实现，因此严重阻碍了鼓励程序员使用更现代风格的努力。
The effort to standardize C++, which had begun in 1989, was officially converted into an international effort under the auspices of ISO.
1989年开始的C++标准化工作正式转变为ISO主持下的国际工作。
However, this made no practical difference as even the organizational meeting in 1989 had large non-US participation.
The main difference is that we refer to ISO C++ rather than ANSI C++.
主要区别在于我们引用的是ISO C++，而不是ANSI C++。
The C++ programmer — and would-be C++ programmer — could now choose from among about 100 books of greatly varying aim, scope, and quality.
现在，C++程序员和未来的C++程序员可以从大约100本目标、范围和质量迥异的书籍中进行选择。
Basically, 1991 was an ordinary, successful year for the C++ community.
基本上，1991年对于C++社区来说是一个普通而成功的一年。
It didn’t particularly stand out from the years before or after. The reason to start our story here is that my HOPL-II paper [120] left off in 1991.
无论是之前还是之后，它都没有特别突出。我们的故事之所以从这里开始，是因为我的HOPL-II论文【120】于1991年发表。
3.1 The ISO C++ Standards Process(ISO C++标准过程)
For the C++ community, the ISO standards process is central: The C++ community has no other formal center, no other forum for driving language evolution, no other organization that cares for the language itself and for the community as a whole.
对于C++社区来说，ISO标准过程是核心：C++社区没有其他正式的中心，没有其他推动语言发展的论坛，没有其他关心语言本身和整个社区的组织。
C++ has no owner corporation that determines a path for the language, finances its development, and provides marketing.
C++没有自己的公司来决定语言的发展方向，为语言的开发提供资金，并提供市场营销。
Therefore, the C++ standards committee became the place where language and standard library evolution is seriously considered.
因此，C++标准委员会成为了认真考虑语言和标准库演变的地方。
To a large extent, the 1991-2006 evolution of C++ was determined by what could be done by the volunteer individuals in the committee and how far the dreaded “design by committee” could be avoided.
在很大程度上，1991-2006年C++的发展取决于委员会中的志愿者可以做什么，以及可以避免可怕的“委员会设计”的程度。
The American National Standards Institute committee for C++ (ANSI J16) was founded in 1989; it now works under the auspices of INCITS (InterNational Committee for Information Technology Standards, a US organization). In 1991, it became part of an international effort under the auspices of ISO.
美国国家标准协会C++委员会（ANSI J16）成立于1989年；它现在在美国组织信息技术标准国际委员会（INCITS）的支持下工作。1991年，它成为ISO赞助下的国际努力的一部分。
Several other countries (such as France, Japan, and the UK) have their own national committees that hold their own meetings (in person or electronically) and send representatives to the ANSI/ISO meetings.
其他几个国家（如法国、日本和英国）都有自己的国家委员会，这些委员会举行自己的会议（亲自或以电子方式），并派代表参加ANSI/ISO会议。
Up until the final vote on the C++98 standard [63] in 1997, the committee met three times a year for week-long meetings. Now, it meets twice a year, but depends far more on electronic communications
in between meetings.
在1997年对C++98标准进行最后表决之前，委员会每年举行三次为期一周的会议。现在，它每年召开两次会议，但更多地依赖于电子通信在会议间隙。
The committee tries to alternate meetings between the North American continent and elsewhere, mostly Europe.
该委员会试图在北美大陆和其他地方（主要是欧洲）轮流举行会议。
The members of the J16 committee are volunteers who have to pay (about $800 a year) for the privilege of doing all the work.
J16委员会的成员是志愿者，他们必须支付（每年约800美元）的费用才能完成所有工作。
Consequently, most members represent companies that are willing to pay fees and travel expenses, but there is always a small number of people who pay their own way.
因此，大多数会员代表愿意支付费用和差旅费的公司，但总有少数人自己支付费用。
Each company participating has one vote, just like each individual, so a company cannot stuff the committee with employees.
每个参与的公司都有一票，就像每个人一样，所以公司不能在委员会里塞满员工。
People who represent their nations in the ISO (WG21) and participate in the national C++ panels pay or not according to their national standards organization rules.
在ISO（WG21）中代表其国家并参加国家C++小组的人员根据其国家标准组织规则付费或不付费。
The J16 convener runs the technical sessions and does formal votes. The voting procedures are very democratic. First come one or more “straw votes” in a working group as part
of the process to improve the proposal and gain consensus.
J16召集人主持技术会议并进行正式投票。投票程序非常民主。首先是工作组中的一个或多个“草签”作为一部分改进提案并获得共识的过程。
Then come the more formal J16 votes in full committee where only accredited members vote. The final (ISO) votes are done on a per-nation basis.
然后是更正式的J16全体委员会投票，只有经认可的成员投票。最终（ISO）投票是在每个国家的基础上进行的。
The aim is for consensus, defined as a massive majority, so that the resulting standard is good enough for everybody, if not necessarily exactly what any one member would have preferred.
其目的是达成共识，即绝大多数，以便最终的标准对每个人都足够好，即使不一定是任何一个成员都会喜欢的标准。
For the 1997/1998 final standards ballot, the ANSI vote was 43-0 and the ISO vote 22-0.
在1997/1998年的最终标准投票中，ANSI的投票结果是43-0，ISO的投票结果是22-0。
We really did reach consensus, and even unanimity. I’m told that such clear votes are unusual.
我们确实达成了共识，甚至是一致意见。有人告诉我，如此明确的投票是不寻常的。
The meetings tend to be quite collegial, though obviously there can be very tense moments when critical and controversial decisions must be made. For example, the debate
leading up to the export vote strained the committee (§5.2).
这些会议往往是相当合议的，尽管很明显，当必须做出关键和有争议的决定时，会有非常紧张的时刻。例如，辩论
在出口投票之前，委员会感到紧张（§5.2）。
The collegiality has been essential for C++. The committee is the only really open forum where implementers and users
from different — and often vigorously competing — organizations can meet and exchange views.
协作性对于C++来说是必不可少的。委员会是唯一一个真正开放的论坛，实施者和用户来自不同的组织（通常是激烈竞争的组织）可以会面并交换意见。
Without a committee with a dense web of professional, personal, and organizational connections, C++ would have broken into a mess of
feuding dialects.
如果没有一个拥有专业、个人和组织联系的密集网络的委员会，C++将陷入一片混乱相互争斗的方言。
The number of people attending a meeting varies between 40 and 120. Obviously, the attendance increases when the meeting is in a location with many C++ programmers (e.g., Silicon Valley) or something major is being decided (e.g., should we adopt the STL?).
参加会议的人数在40到120人之间。显然，当会议地点有许多C++程序员（如硅谷）或正在决定一些重大事项（如我们是否应该采用STL？）时，出席人数会增加。
At the Santa Cruz meeting in 1996, I counted 105 people in the room at the same time.
在1996年的圣克鲁斯会议上，我同时统计了房间里的105人。
Most technical work is done by individuals between meetings or in working groups. These working groups are officially “ad hoc” and have no formal standing.
大多数技术工作都是在会议间隙或在工作组中由个人完成的。这些工作组是正式的“特设”工作组，没有正式地位。
However, some lasts for many years and serve as a focus for work and as the institutional memory of the committee.
然而，其中一些会持续多年，成为委员会工作的重点和机构记忆。
The main long-lived working groups are:(主要的长期工作组包括)
• Core — chairs: Andrew Koenig, Josée Lajoie, Bill Gibbons, Mike Miller, Steve Adamczyk.
核心主席：安德鲁·柯尼格、何塞·拉乔伊、比尔·吉本斯、迈克·米勒、史蒂夫·阿达姆齐克。
• Evolution (formerly extensions) — chair: Bjarne Stroustrup.
Evolution（前身为extensions）——主席：比亚恩·斯特劳斯特鲁普。
• Library — chairs: Mike Vilot, Beman Dawes, Matt Austern, Howard Hinnant. When work is particularly hectic, these groups split into subworking-groups focussed on specific topics.
The aim is to increase the degree of parallelism in the process and to better use the skills of the many people present.
The official “chair” of the whole committee whose primary job is the ensure that all formal rules are obeyed and to report back to SC22 is called the convener. The original
convener was Steve Carter (BellCore). Later Sam Harbinson (Tartan Labs and Texas Instruments), Tom Plum (Plum Hall), and Herb Sutter (Microsoft) served.
全体委员会的正式“主席”称为召集人，其主要工作是确保遵守所有正式规则并向SC22报告。原件召集人是史蒂夫·卡特（BellCore）。后来，萨姆·哈宾逊（Tartan Labs and Texas Instruments）、汤姆·普卢姆（Plum Hall）和赫伯·萨特（Herb Sutter）（Microsoft）担任了该职位。
The J16 chairman conducts the meeting when the whole committee is gathered. Dmitri Lenkov (Hewlett-Packard) was the original J16 chair and Steve Clamage (Sun) took
over after him.
J16主席在全体委员会开会时主持会议。Dmitri Lenkov（Hewlett-Packard）是最初的J16座椅，Steve Clamage（Sun）担任在他后面。
The draft standard text is maintained by the project editor. 标准文本草案由项目编辑器维护。
The original project editor was Jonathan Shopiro (AT&T). 最初的项目编辑是乔纳森·肖皮罗（美国电话电报公司）。
He was followed by Andrew Koenig (AT&T) whose served 1992-2004, after which Pete Becker (Dinkumware) took over “the pen”.
紧随其后的是安德鲁·柯尼格（美国电话电报公司）（AndrewKoenig），他于1992年至2004年任职，之后皮特·贝克尔（Dinkumware）接手了《笔》。
The committee consists of individuals of diverse interests,concerns, and backgrounds. Some represent themselves, some represent giant corporations. Some use PCs, some use
UNIX boxes, some use mainframes, etc.
该委员会由具有不同兴趣、关切和背景的个人组成。有些代表自己，有些代表大公司。有些使用PC，有些使用UNIX boxes，一些使用大型机等。
Some would like C++ to become more of an object-oriented language (according to a variety of definitions of “object-oriented”), others would have been more comfortable had ANSI C been
the end point of C’s evolution.
有些人希望C++更像是一种面向对象的语言（根据“面向对象”的各种定义），其他人则希望ANSI C更适合C进化的终点。
Many have a background in C, some do not. Some have a background in standards work, many do not. Some have a computer science background, some do not. Most are programmers, some are not.
Some are language lawyers, some are not. Some serve endusers, some are tools suppliers. Some are interested in large projects, some are not. Some are interested in C compatibility, some are not.
许多人有C语言背景，有些人没有。一些人有标准工作的背景，许多人没有。有些人有计算机科学背景，有些人没有。大多数是程序员，有些不是。有些是语言律师，有些不是。一些服务于最终用户，一些是工具供应商。有些人对大型项目感兴趣，有些人则不感兴趣。有些人对C兼容性感兴趣，有些人则不感兴趣。
It is hard to find a generalization that covers them all.
很难找到一个涵盖所有这些方面的概括。
This diversity of backgrounds has been good for C++; only a very diverse group could represent the diverse interests of the C++ community.
这种背景的多样性对C++有好处；只有非常多样化的团队才能代表C++社区的不同利益。
The end results — such as the 1998 standard and the Technical Reports (§6.1, §6.2) — are something that is good enough for everyone represented,
最终结果——如1998年的标准和技术报告（§6.1，§6.2）——对每个代表来说都足够好，
rather than something that is ideal for any one subcommunity. However, the diversity and size of the membership do make constructive discussion difficult and slow at times.
而不是任何一个子团体的理想选择。然而，成员的多样性和规模确实使建设性的讨论有时困难而缓慢。
In particular, this very open process is vulnerable to disruption by individuals whose technical or personal level of maturity doesn’t encourage them to understand or respect the views of
others.
特别是，这种非常开放的流程很容易被技术或个人成熟度不鼓励他们理解或尊重其他。
Part of the consideration of a proposal is a process of education of the committee members. Some members have claimed — only partly in jest — that they attend to get that education.
审议提案的一部分是对委员会成员的教育过程。一些成员声称（只是部分开玩笑）他们参加是为了接受教育。
I also worry that the voice of C++ users (that is, programmers and designers of C++ applications) can be drowned by the voices of language lawyers, would-be language designers, standards bureaucrats, implementers, tool builders, etc.
我还担心C++用户（即C++应用程序的程序员和设计师）的声音可能会被语言律师、潜在的语言设计师、标准官僚、实施者、工具构建者等的声音淹没。
To get an idea about what organizations are represented, here are some names from the 1991-2005 membershiplists: Apple, AT&T, Bellcore, Borland, DEC, Dinkumware,
Edison Design Group (EDG), Ericsson, Fujitsu, HewlettPackard, IBM, Indiana University, Los Alamos National Labs, Mentor Graphics, Microsoft, NEC, Object Design,
Plum Hall, Siemens Nixdorf, Silicon Graphics, Sun Microsystems, Texas Instruments, and Zortech.
为了了解哪些组织是有代表性的，以下是1991-2005年成员名单中的一些名称：苹果、AT&T、Bellcore、Borland、DEC、Dinkumware、，
爱迪生设计集团（EDG）、爱立信、富士通、HewlettPackard、IBM、印第安纳大学、洛斯阿拉莫斯国家实验室、Mentor Graphics、微软、NEC、Object Design、，
Plum Hall、Siemens Nixdorf、Silicon Graphics、Sun Microsystems、Texas Instruments和Zortech。
Changing the definition of a widely used language is very different from simple design from first principles.
Whenever we have a “good idea”, however major or minor, we must remember that
• there are hundreds of millions of lines of code “out there”
— most will not be rewritten however much gain might result from a rewrite
• there are millions of programmers “out there” — most won’t take out time to learn something new unless they consider it essential
• there are decade-old compilers still in use — many programmers can’t use a language feature that doesn’t compile on every platform they support
• there are many millions of outdated textbooks out there
— many will still be in use in five years’ time The committee considers these factors and obviously that gives a somewhat conservative bias. Among other things, the members of the committee are indirectly responsible for well over 100 million lines of code (as representatives of their organizations). Many of the members are on the committee to promote change, but almost all do so with a great
sense of caution and responsibility. Other members feel that their role is more along the lines of avoiding unnecessary and dangerous instability. Compatibility with previous versions of C++ (back to ARM C++ [35]), previous versions of C (back to K&R C [76]), and generations of corporate dialects is a serious issue for most members. We (the members of the committee) try to face future challenges, such as conEvolving C++ 1991-2006 7 2007/5/25 currency, but we do so remembering that C++ is at the base of many tool chains.
Break C++ and the major implementations of Java and C# would also break. Obviously, the committee couldn’t “break C++” by incompatibilities even if it
wanted to. The industry would simply ignore a seriously incompatible standard and probably also start migrating away from C++.
3.2 Chronology(大事记)
Looking forward beyond 1991, we can get some idea of the process by listing some significant decisions (votes):
展望1991年以后，我们可以通过列出一些重要决策（投票）来了解这一过程：
1993 Run-time type identification accepted (Portland, Oregon) §5.1.2; namespaces accepted (Munich, Germany) §5.1.1
1993年接受运行时类型识别（俄勒冈州波特兰）§5.1.2；接受名称空间（德国慕尼黑）§5.1.1
1994 string (templatized by character type) (San Diego, California)
1994字符串（按字符类型模板化）（加利福尼亚州圣地亚哥）
1994 The STL (San Diego, California) §4.1 1994 STL（加利福尼亚州圣地亚哥）§4.1
1996 export (Stockholm, Sweden) §5.2 1996年 export（瑞典斯德哥尔摩）§5.2
1997 Final committee vote on the complete standard (Morristown, New Jersey) 1997年委员会对完整标准的最终投票（新泽西州莫里斯镇）
1998 ISO C++ standard [63] ratified 1998年批准ISO C++标准[63]
2003 Technical Corrigendum (“mid-term bug-fix release”) [66]; work on C++0x starts
2003年技术勘误表（“中期错误修复版本”）[66]；开始使用C++0x
2004 Performance technical report [67] §6.1; Library Technical Report (hash tables, regular expressions, smart pointers, etc.) [68] §6.2
2004年性能技术报告【67】§6.1；库技术报告（哈希表、正则表达式、智能指针等）[68]§6.2
2005 1st votes on features for C++0x (Lillehammer, Norway); auto, static_assert, and rvalue references accepted in principle; §8.3.2
2005年对C++0x的特性进行了第一次投票（Lillehammer，挪威）；原则上接受auto、static\u assert和rvalue引用；§8.3.2
2006 1st full committee (official) votes on features for C++0x (Berlin, Germany) The city names reflect the location of the meeting where the decision was taken. They give a flavor of the participation.
When the committee meets in a city, there are usually a dozen or more extra participants from nearby cities and countries. It is also common for the host to take advantage of the influx of C++ experts — many internationally known —
to arrange talks to increase the understanding of C++ and its standard in the community. The first such arrangement was in Lund in 1991 when the Swedish delegation collaborated
with Lund University to put on a two-day C++ symposium.
2006年第一届全体委员会（官方）对C++0x（德国柏林）的功能进行投票城市名称反映了做出决定的会议地点。他们给人一种参和的感觉。
当委员会在一个城市开会时，通常会有十几个或更多来自附近城市和国家的额外参与者。主持人利用C++专家的涌入也是很常见的，许多专家都是国际知名的-
安排会谈，提高社区对C++及其标准的理解。第一次这样的安排是1991年在隆德，当时瑞典代表团进行了合作与隆德大学举行为期两天的C++研讨会。
This list gives a hint of the main problem about the process from the point of view of someone trying to produce a coherent language and library, rather than a set of unrelated “neat features”. At any time, the work focused on a number
of weakly related specific topics, such as the definition of “undefined”, whether it is possible to resume from an exception (it isn’t), what functions should be provided for string, etc.
这个列表从试图产生一种连贯的语言和库的角度，而不是从一组不相关的“整洁特性”的角度，暗示了该过程的主要问题。在任何时候，工作重点都是弱相关的特定主题，如“未定义”的定义、是否可以从异常恢复（不是）、应为字符串提供哪些函数等。
It is extremely hard to get the committee to agree on an overall direction
很难让委员会就总体方向达成一致
3.3 Why Change?
Looking at the list of decisions and remembering the committee’s built-in conservative bias, the obvious question is:
“Why change anything?” There are people who take the
position that “standardization is to document existing practice”. They were never more than a tiny fraction of the committee membership and represent an even smaller proportion
of the vocal members of the C++ committee. Even people
who say that they want “no change” ask for “just one or two
improvements”. In this, the C++ committee strongly resembles other language standardization groups.
Basically, we (the members of the committee) desire
change because we hold the optimistic view that better language features and better libraries lead to better code. Here,
“better” means something like “more maintainable”, “easier
to read”, “catches more errors”, “faster”, “smaller”, “more
portable”, etc. People’s criteria differ, sometimes drastically.
This view is optimistic because there is ample evidence that
people can — and do — write really poor code in every language. However, most groups of programmers — including
the C++ committee — are dominated by optimists. In particular, the conviction of a large majority of the C++ committee has consistently been that the quality of C++ code can
be improved over the long haul by providing better language
features and standard-library facilities. Doing so takes time:
in some cases we may have to wait for a new generation
of programmers to get educated. However, the committee is
primarily driven by optimism and idealism — moderated by
vast experience — rather than the cynical view of just giving
people what they ask for or providing what “might sell”.
An alternative view is that the world changes and a living
language will change — whatever any committee says. So,
we can work on improvements — or let others do it for us.
As the world changes, C++ must evolve to meet new challenges. The most obvious alternative would not be “death”
but capture by a corporation, as happened with Pascal and
Objective C, which became Borland and Apple corporate
languages, respectively.
After the Lund (Sweden) meeting in 1991, the following
cautionary tale became popular in the C++ community:
We often remind ourselves of the good ship Vasa. It
was to be the pride of the Swedish navy and was
built to be the biggest and most beautiful battleship
ever. Unfortunately, to accommodate enough statues
and guns, it underwent major redesigns and extension
during construction. The result was that it only made
it halfway across Stockholm harbor before a gust of
wind blew it over and it sank, killing about 50 people.
It has been raised and you can now see it in a museum
in Stockholm. It is a beauty to behold — far more
beautiful at the time than its unextended first design
and far more beautiful today than if it had suffered the
usual fate of a 17th century battleship — but that is
no consolation to its designer, builders, and intended
users.
This story is often recalled as a warning against adding features (that was the sense in which I told it to the committee).
However, to complicate matters, there is another side to the
story: Had the Vasa been completed as originally designed,
it would have been sent to the bottom full of holes the first
time it encountered a “modern two-deck” battleship. Ignoring changes in the world isn’t an option (either).
4. The Standard Library: 1991-1998
After 1991, most major changes to the draft C++ standard
were in the standard library. Compared to that, the language
features were little changed even though we made an apparently infinite number of improvements to the text of the
standard. To gain a perspective, note that the standard is 718
pages: 310 define the language and 366 define the standard
library. The rest are appendices, etc. In addition, the C++
standard library includes the C standard library by reference;
that’s another 81 pages. To compare, the base document
for the standardization, the reference manual of TC++PL2
[118], contained 154 pages on the language and just one on
the standard library.
By far the most innovative component of the standard
library is “the STL” — the containers, iterators, and algorithms part of the library. The STL influenced and continues to influence not only programming and design techniques but also the direction of new language features. Consequently, this is treated first here and in far greater detail
than other standard library components.
4.1 The STL
The STL was the major innovation to become part of the
standard and the starting point for much of the new thinking
about programming techniques that have occurred since.
Basically, the STL was a revolutionary departure from the
way the C++ community had been thinking about containers
and their use.
4.1.1 Pre-STL containers
From the earliest days of Simula, containers (such as lists)
had been intrusive: An object could be put into a container
if and only if its class had been (explicitly or implicitly) derived from a specific Link and/or Object class. This class
contains the link information needed for management of objects in a container and provides a common type for elements. Basically, such a container is a container of references (pointers) to links/objects. We can graphically represent such a list like this:
.......
|来自:
https://www.stroustrup.com/hopl-almost-final.pdf
