Question

C++ 想发展成什么样？或者说，WG21 对于它在努力做什么有一个清晰的观点么？我认为答案是否定的。每位成员对于这个问题都有想法，但没有一个想法既被广泛接受，同时又足够具体到可以指导实际的讨论和决策。

ISO C++ 标准委员会既没有一组得到广泛认可的设计标准，也没有一组得到广泛认可的采纳某个特性的标准。这并不是因为缺少这方面的尝试。我曾经反复不断地明确强调以下设计标准：

• 在《C++ 语言的设计和演化》[Stroustrup 1994]（§2.1）中提出的经验法则包括 RAII（§2.2.1）、面向对象编程、泛型编程和静态类型安全。
• 简单的事情简单做！（§4.2）则引出洋葱原则（§4.2）。
• 从代码到硬件的直接映射和零开销抽象（§1）（§11.2）。
• 基于意见反馈来发展 C++，以解决现实世界的实际问题（§11.2）。
• 保持稳定性和兼容性 [Koenig and Stroustrup 1991b; Stroustrup 1994]。
• 直接和硬件打交道的能力，强有力的可组合的抽象机制，以及最小化的运行时系统（参见我在 HOPL3 的论文 [Stroustrup 2007] 中的回顾）。

问题在于，人们发现要在解释上达成一致太难，而要忽视他们所不喜欢的又太容易。这种倾向，使得在什么才是重要的这个问题上的根本分歧得以发酵。大家基于他们所受的教育和他们的日常工作中所获得的理解，来做出设计决策。这种背景上的多样性，再加上标准委员会内部对于 C++ 广泛应用领域的不均衡覆盖（§3.3），就构成了一个问题。许多人只是对于自己的观点过于确定无疑 [Stroustrup 2019b]。而要分辨清楚到底什么只是一时的流行，什么从长远来看才对 C++ 社区有帮助，确实很困难。通常来说，第一个提出的解决方案往往不是最好的那个。

人们很容易在细节中迷失而忽略了大局。人们很容易关注当前的问题而忘记长期目标（以十年计）。相反，委员会成员是如此专注于通用的原则和遥远的未来，以至于对迫在眉睫的实际问题视而不见。

在 2017 年，一群国家标准机构代表团的领导人 [van Winkel et al. 2017] 要求对 C++ 的方向性问题予以正式严肃的考量，在他们的敦促之下，WG21 建立了方向组（Direction Group，通常称之为 DG）以试图解决设计目标和方向的问题（§3.2）。DG 在 2018 年 发布了它的第一个广泛而详尽的声明 [Dawes et al. 2018]，强调了要遵守明确清晰的原则、一致性，并鼓励用流程来确保这些。比如说：

我们从根本上需要：

• 稳定性：有用的代码存活达数十年。
• 不断演进：世界在不断变化，而 C++ 也需要不断改变以面对新的挑战。

这里有一种内在的张力。

DG 强调一致性有必要贯穿整个标准：

现如今，某些最为强大的设计技术融合了传统的面向对象编程方面、泛型编程方面、函数式编程方面以及一些传统的命令式编程技术。这种组合，而不是理论上的纯粹，才是理想的。

• 提供在风格（语法和语义）和使用风格上一致的特性。

该要求适用于库、语言特性，以及这两者的组合

当然了，还有静态类型：

C++ 极其依赖于静态类型安全，以达成其表达能力、性能和安全性。理想的情况下应有

• 完全的类型安全和资源安全（没有内存损坏和内存泄漏）

该要求可以在不增加额外开销的情况下达成，尤其是，不需要添加垃圾收集器，也不需要限制表达能力。

国家机构领导的要求 [van Winkel et al. 2017] 和 DG 的文档 [Dawes et al. 2018] 都强调了委员会成员需要了解 C++ 的历史，以确保一定程度的连续性。一个缺乏历史的组织无法对他们的设计内容保持一致性的观点。因此，HOPL 论文 [Stroustrup 1993, 2007] 和《C++ 语言的设计和演化》[Stroustrup 1994] 扮演了基石角色。

传统上，为符合 WG21 在 ISO 的章程，C++ 演化方面的工作主要都聚焦于语言和库的课题。然而，开发者不仅仅需要考虑语言：程序是工具链（§1）的产物。令人震惊的是，C++ 并没有关于动态链接库的标准，也没有标准化的构建系统。工具研究小组 SG15 在 2018 年成立，以尝试应对工具方面的形形色色的问题（§3.2）。