Question

最初，我设计 C++ 是为了回答这样的一个问题：如何直接操作硬件，同时又支持高效、高级的抽象？C++ 在 1980 年代仅仅是一个基于 C 和 Simula 语言功能的组合，在当时的计算机上作为系统编程的相对简单的解决方案，经过多年的发展，已经成长为一个远比当年更复杂和有效的工具，应用极其广泛。它保持 了如下两方面的关注：

• 语言构件到硬件设施的直接映射
• 零开销抽象

这种组合是 C++ 区别于大多数语言的决定性特征。零开销是这样解释的 [Stroustrup 1994]：

• 你不用的东西，你就不需要付出代价（没有四处散落的赘肉）。
• 你使用的东西，你手工写代码也不会更好。

抽象在代码中体现为函数、类、模板、概念和别名。

C++ 是一种活的语言，因此它会不断变化以应对新出现的挑战和演变中的使用风格。2006 年至 2020 年期间的这些挑战和变化是本文的重点。当然，一门语言本身不会改变；是人们改变了它。所以这也是参与 C++ 演化的人们的故事，他们识别出面临的挑战，诠释解决方案的局限，组织他们的工作成果，并解决他们之间必然出现的分歧。当我呈现一种语言或标准库特性时，其 背景是 C++ 的一般发展和当时参与者的关切。对于在早期被接受的许多特性，我们现在从大量的工业使用中获得了后见之明。

C++ 主要是一种工业语言，一种构建系统的工具。对于用户来说，C++ 不仅仅是一种由规范定义的语言；它是由许多部分组成的工具集的一部分：

• 语言
• 标准库
• 许多的其他库
• 庞大的——常常是旧的——代码库
• 工具（包括其他语言）
• 教学和培训
• 社区支持

只要有可能，只要合适，我就会考虑这些组成部分之间的相互作用。

有一种流传广泛的谬见，就是程序员希望他们的语言是简单的。当你不得不学习一门新的语言、不得不设计一门编程课程、或是在学术论文中描述一门语言 时，追求简单显然是实情。对于这样的用途，让语言干净地体现一些明确的原则是一个明显的优势，也是理想情况。当开发人员的焦点从学习转移到交付和维护重要 的应用程序时，他们的需求从简单转移到全面的支持、稳定性（兼容性）和熟悉度。人们总是混淆熟悉度和简单，如果可以选择的话，他们更倾向于熟悉度而不是简 单。

看待 C++ 的一种方式是，把它看成几十年来三种相互矛盾的要求的结果：

• 让语言更简单！
• 立即添加这两个必要特性！！
• 不要搞砸我的（任何）代码！！！

我添加了感叹号，因为这些观点的表达常常带着不小的情绪。

我想让简单的事情简单做，并确保复杂的事情并非不可能，也不会没有必要地难。前者对于不是语言律师的开发者来说是必不可少的；后者对于基础性代码的实现者是必要的。稳定是所有意图持续运行几十年的系统的基本属性，然而一种活的语言必须适应不断变化的世界。

C++ 有一些总体构想。我阐述了一些（如《C++ 语言的设计和演化》（The Design and Evolution of C++）[Stroustrup 1994]（§2）、设计原则（§9.1），以及 C++ 模型（§11.1））并试图让语言在演化时遵循它们。然而，C++ 的开发由 ISO 标准委员会控制，它主要关注的是长长的新特性列表，以及对实际细节的关心。这是社区里最能表达和最有影响力的人所坚持的东西，仅仅基于哲学或理论观点就否认他们的关切和意见的话，恐怕就失之鲁莽了。