摘要：然而，伴随着对更高安全性和效率的需求，C++ 的未来正面临愈发明显的分裂。近日，软件工程师 Mond 发布的《The Two Factions of C++》一文引发了热烈讨论，他详细剖析了这门语言当前的困境：一方面是现代技术企业对更高性能和工具链的渴望，另一

C++，这门承载了数十年辉煌历史的编程语言，曾是系统软件、游戏开发和数据库系统等

然而，伴随着对更高安全性和效率的需求，C++ 的未来正面临愈发明显的分裂。近日，软件工程师 Mond 发布的《The Two Factions of C++》一文引发了热烈讨论，他详细剖析了这门语言当前的困境：一方面是现代技术企业对更高性能和工具链的渴望，另一方面则是庞大的遗留代码库对向后兼容性的刚性要求。与此同时，C++标准委员会试图在不破坏现有代码的前提下引入新特性，这种努力能否弥合分歧，仍是悬而未决的问题。

声明：本文为 CSDN 翻译，未经允许禁止转载。

作者 | Mond 翻译 | 屠敏

出品 | CSDN（ID：CSDNnews）

关于 C++ 的未来，近段时间似乎引发不少的争论。无论是在 Reddit、HN 上，还是在 C++ 标准委员会的会议上，四处可见这些讨论。

C++ 的现状

当前，我们所使用的 C++ 似乎正处于以下局面：

1. C++ 的演进工作组（EWG）刚刚就采纳 P3466 R0 达成共识——即，(重新)确认未来 C++ 演进的设计原则：

不允许 ABI（应用二进制接口）中断，保持与 C 以及早期 C++ 版本的链接兼容性。

不引入“病毒式注解”（例如，不支持生命周期注解）。

坚持一组互相矛盾的目标，例如同时要求不破坏 ABI 和零开销原则。

这无论这是好是坏，都表明 C++ 的发展方向在进一步巩固当前的轨迹。

2. 与此同时，一方面，美国政府希望人们停止使用 C++：

美国网络安全和基础设施安全局(CISA)

美国国家安全局(NSA)

甚至白宫

截至目前，美国政府的各个部门已经发布了文件、报告和建议，警告行业不要使用内存不安全的语言。

3. 各种大型科技公司正在采用 Rust：

微软显然正在用 Rust 重写核心库：去年 10 月，微软在 GitHub 中发布了一系列开发工具包，让开发者可以使用 Rust 语言来编写 Windows 驱动程序。

谷歌似乎也致力于 Rust：其先是宣布支持使用 Rust 开发 Chromium，同时也开发一个双向 C++/Rust 互操作工具。

2019 年，AWS 表示开始在其基础架构中越来越多地使用 Rust 后，决定赞助 Rust，即 Rust 团队可以优惠租用 AWS 基础设施以进行语言开发。

......

说到大型科技公司，近期还有几件事值得注意：

不久前，ISO C++ 委员会主席 Herb Sutter 在其个人博客宣布，他已经离开了工作 22 年的微软，正式成为金融公司 Citadel Securities 的一名技术研究员。而 MSVC（Microsoft Visual C+）似乎在实现 C++23 功能上进展缓慢，还在向社区征求优先级意见。

臭名昭著的布拉格 ABI 投票事件发生了（简而言之：“C++ 23 不会破坏 ABI，将来是否会破坏也尚不明朗。”），据说 Google 大幅减少了参与 C 开发过程的工作，转而开始开发自己的 C++ 后续语言——Carbon。他们甚至写了一个文档，总结他们在尝试改进 C++ 时遇到的种种困难（https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/difficulties_improving_cpp.md）。

4. 社区中的问题：

之前有很多人分享过自己尽最大努力参与 C++ 标准委员会的过程，但最终却被消耗殆尽。即使有些功能在 C 中实现了也没有什么用。

事到如今，模块功能尚未实现。我们有模块了吗？答案是否定的。

相信不少人还记得在 2023 年 CppCon 2023 的演讲中，C++ 之父 Bjarne Stroustrup 首次提出了安全配置文件（Safety Profiles）的概念，目的是为 C++ 提供更强的类型和资源安全性，同时尽量避免破坏现有的兼容性。Safety Profiles 的核心是通过一组规则和工具引导开发者编写更安全的代码，同时允许不同的项目根据需求选择适合的安全级别。然而，“安全配置文件”（Safety Profiles）仍处于一种奇怪的状态，没有任何现有实现，它试图在尽量减少对现有代码更改的情况下，为现有的 C++ 代码增加某种程度的安全性。C++ 联盟开发人员 Sean Gaxter（Circle 编译器的创造者）本人公开反对配置文件，称 C++ 为“定义不足”的语言。

我不知道你怎么看，但如果我作为一个外行人来看待这一切，C++ 似乎基本上已经分崩离析了，而且似乎很多人已经对 C++ 委员会能够处理这些问题的能力失去了信心。

C++ 的两大派系

人们似乎正在寻找其他解决方案。

比如说 Google。自从 ABI 投票以来，Google 显然对“这一标准化流程”失去了信心。这种失望并非针对 C++ 语言本身——Google 自己拥有庞大的 C++ 代码库，这门语言对他们来说一直表现出色。然而，他们对 C++ 在多方压力（如潜在的政府监管、其他语言的竞争、大厂对更高性能和安全保障的需求等）下继续演进的能力失去了信心。

那么问题出现在哪里？为什么 C++ 不能做出改变呢？

答案其实很简单。我们可以参考 ISO C++ 委员会主席 Herb Sutter 在其关于配置文件的论文中所说的话：

“我们必须尽量减少对现有代码的修改需求。根据几十年的经验，对于拥有大型代码库的大多数客户来说，即便是为了安全原因，也不会因为严格性规则而修改哪怕 1% 的代码，除非有法规要求强制执行。”

——Herb Sutter

这很合理，不是吗？没人对此感到惊讶。

现在，对比一下 Google 工程师 Chandler Carruth 在 WG21 成员页面上的简介：

“我主导了基于 Clang 的 C++ 工具和自动化重构系统的设计，这些工具现在已成为 Clang 项目的一部分……

在 Google 内部，我带领团队将这些基于 Clang 的自动化重构工具扩展到整个代码库，超过 1 亿行 C++ 代码。我们可以在 20 分钟内对整个代码库进行分析并应用重构。”

看到了吗？这里 Chandler Carruth 提到了一个关键词是“自动化工具”。但不只是自动化迁移工具，这只是最显眼的例子。

两种 C++ 用户阵营的对立

实际上，我们看到的是两种完全不同的 C++ 用户阵营之间的冲突：

相对现代、有能力的技术公司，它们明白自己的代码是一种资产。（这并不严格限于大科技公司。任何新兴的 C++ 初创公司也属于这一类。）

其他所有人。那些仍在争论如何缩进代码的老牌公司，以及年轻工程师试图说服管理层允许他设置代码检查工具的情况。

这两种用户之间的关键区别在于：前者能够相对顺利地应对迁移，因为他们能从版本化源码构建整个 C++ 栈，而后者则仍在使用 1998 年的老旧库。

这种能力——从版本化源码构建整个依赖栈（最好还带有自动化测试）——是两大阵营之间最重要的分水岭。

当然，在实践中，这是一个渐进的过程。我可以想象，要把大公司的代码库从可怕的泥球变成半可管理、可构建、经过代码检查、适当版本化、稍微不那么可怕的泥球，必须流下多少汗水、泪水、账单和心血。

事后看来，很容易认为这一切都是不可避免的：像 Google 这样的公司（使用相对现代的 C++，拥有自动化工具和测试，以及现代基础设施）的需求与强烈向后兼容的愿望之间存在明显的脱节。

大胆地说，单一、无方言且统一的 C++ 的概念似乎已经死多年了。至少，我们有两种主流风格的 C++：

稍微现代化一点的 C++。一切都可以通过某种专用、干净且统一的构建流程从版本化的源码构建，至少比原始 CMake 稍微复杂一些，如果稍微眯着眼睛看，它就能正常工作。包含一些静态分析器、格式化程序、代码检查器。任何一种保持代码库清洁和现代化是有价值的共识。可能至少是 C++17，带有`unique_ptr`、`constexpr`、`optional`等特性，但这不是重点。重要的是工具。

传统的 C++。即任何不符合上述条件的 C++。比如那些存放在中型银行古老服务器上的 C++。任何依赖于某个完全古老且已编译代码块的 C++，其源码已经丢失，原作者也无法联系。任何部署在宠物类型服务器上的 C++，以至于在其他地方启动它需要工程师花整整一个月的时间来弄清楚所有隐含的依赖项、配置和环境变量。这些主要被归类为成本中心的代码库。任何从源码构建使用的二进制文件都需要按下不止几个按钮，或者根本无法构建的代码。

你会注意到，这两种文化的分歧不在于 C++ 语言本身，而是工具和是否能从版本化源码进行干净、有定义的构建。理想情况下，甚至能够在不需要记住以前开发者通常设置的那个标志或环境变量的情况下进行部署。

例如，Google 的代码库是否完全采用“现代” C++ 习惯用法并不是重点。关键是工具是否到位，以及是否能够从源码构建。

很多人会说工具不是 C++ 标准委员会的责任，这观点是对的。工具确实不是 C++ 标准委员会的责任，因为 C++ 标准委员会放弃了对它的责任（他们专注于语言规范，而非具体的实现）。这是设计使然，考虑到遗留负担很难去责怪他们。C++ 是一个统一不同实现的标准。

话虽如此，如果说 Go 语言有一件事做对了，那就是他们把工具放得很重要。相比之下，C++ 出生于一个比 linter 更古老的时代。C++ 没有统一的构建系统，也没有接近统一的包管理系统，语法复杂难以解析（这对工具来说很糟糕），且每次改动都在与 Hyrum 定律作斗争。

这两个派系（良好的工具，可以毫不费力地从源码构建 vs. 差劲的工具，无法从源码构建）之间存在着巨大的、不断扩大的裂痕，而且短期内看不到弥合的可能性。

C++ 委员会似乎坚决维护向后兼容性，无论代价如何。

顺便说一句，我并不一定反对这一点！向后兼容性对许多人来说非常重要，理由充分。然而，对另一些人而言，这并不重要。这不是谁“对”的问题，而是两种截然不同、无法调和的立场之间的冲突。

造成的后果

这就是为什么配置文件的设计是这样的：安全配置文件的目的并不是为了解决现代、技术娴熟的 C++ 公司的需求。它们是为了在不需要对旧代码进行任何更改的情况下带来改进。

同样地，对于模块也是如此。设计初衷是让你“只需”以模块形式导入头文件，而不会引发任何向后兼容性问题。

毫无疑问，大家都喜欢那些可以直接引入并在不改动旧代码的情况下带来改进的功能。但很明显，这些功能的设计初衷是为了迎合“传统 C++”的需求。任何需要从传统 C++ 迁移的功能对 C++ 标准委员会来说都是不可行的，因为正如 Herb Sutter 所说，你基本上不能指望人们自己去迁移。

（再次强调，考虑传统 C++ 的需求并不是坏事。这完全是一个合理的决策。）

这一点我始终牢记在心，每当我阅读 C++ 提案时都会注意：C++ 其实有两个主要受众群体。一是现代 C++ 用户，另一个是传统 C++ 用户。这两个阵营对许多问题的看法大相径庭，且许多提案都是针对其中一个特定群体的需求而撰写的。

显然，这导致了许多人无法互相理解，话说不到一块：尽管许多人以为安全配置文件和 safe C++ 是在解决同样的问题，实际上它们面向的是完全不同的受众，解决的是完全不同的问题。

C++ 委员会正试图阻止这种裂痕进一步扩大。这或许就是为什么 Sean Baxter 撰写的《 Safe C++》对他们来说毫无意义的原因。这种提案是一种激进且全面的变革，可能会开创一种完全不同的 C++ 编程方式。

当然，也有人提出另一个问题：是否某些 C++ 标准委员会成员只是过于固执，抓住各种理由来阻止他们个人在审美上不认可的演进。

这是否属实，我不便评判，但关于 C++ 标准委员会应用“双重标准”的说法并非首次听闻。比如“如果你想让这个提案被通过，我们要求你提供多个编译器的完整、可用的实现；但我们仍然愿意支持某些大项目（例如模块、配置文件），即便这些项目根本没有任何可用的概念验证实现。”

如果真是如此（我无法确证），我无法预测 C++ 还能沿着这条道路走多久，除非最终发生更为剧烈的分裂。

更不用提，打破 ABI 兼容性可能引发的巨大麻烦和一系列问题，那简直就是个无底洞。

C++ 未来将何去何从？

面对现代企业和遗留系统给 C++ 社区内部带来两极分化的趋势，不少网友看法不一。

来自 Reddit 的用户 ravixp 表示：

这让我感同身受，也许是因为我曾亲眼看到一个非常大的 C++ 代码库在不同层面和不同规模上，从“遗留”C++逐步过渡到“现代”C++的过程。这种转换涉及不同团队以各自的节奏和时间点推进，跨越了数十年的开发周期，至今仍在进行中。而任何新的代码现代化计划，都需要面对代码库中各部分的现代化水平不一致的问题。

（想象一下试图对这样的代码添加静态分析支持：它同时包含了 std::string、C 风格字符串，以及 20 年前 STL 性能较差时团队自行创建的字符串类型的奇怪中间状态！）

关键在于，现代化的成本非常高昂。这里提到的“现代”C++不仅仅是用不同的方式编写代码，它还包括一整套支持现代化标准的工具体系，这可能需要从零开始构建，还需要一个能够跟上 C++ 演进的工程团队。

需要牢记的是，这里的冲突并不是“喜欢遗留 C++”的人与“喜欢现代 C++”的人之间的矛盾，而是“能负担得起现代 C++”的人与“负担不起”的人之间的矛盾。C++ 的确需要改变，但真正的问题是：我们集体能够承受多少变化的成本，以及如何从中获得最大的价值。

Kronikarz 评价道：

从道德角度来看，我认为这反映了一种分歧：一部分人对 C++ 逐渐变成下一个 COBOL 不以为意，另一部分人则对这一想法感到排斥。

另一位网友 KittensInc 则认为：

遗留 C++ 正在迅速成为一种负担。美国政府已经意识到，通过做出不同的设计决策，可以完全避免某些类型的漏洞，并正在推动人们减少这些错误。我认为，负责管理责任的机构最终会加入这一趋势只是时间问题。

如果像缓冲区溢出这样的漏洞被认为是完全可以预防的，那么从逻辑上讲，如果某次黑客攻击、勒索软件事件或数据泄露的根本原因是缓冲区溢出，保险公司可能会拒绝赔付。这样一来，公司可能会要求软件供应商对其代码库进行第三方静态分析审计。

于是我们到达了这样一个节点：不进行现代化改造的成本变得过高。你要么升级你的代码库，要么你的公司走向灭亡。采用现代开发实践的企业只需运行一些简单的分析工具并完成一些文书工作，而那些没有任何像样工具并且背负着数十年技术债务的公司将陷入严重困境。

对此，你怎么看？

关于现代 C++ 最佳实践、架构设计以及大模型驱动的软件开发等技术前沿，CSDN 与 Boolan 将于 12 月 5-6 日在上海虹桥万豪大酒店隆重举办「2024 全球 C++ 及系统软件技术大会」。大会由 C++ 之父 Bjarne Stroustrup 领衔，联合来自英伟达、阿里巴巴、字节跳动、腾讯、百度和 B 站等顶尖企业的技术专家，通过主题演讲、案例剖析与技术交流，分享行业洞见和实践经验，推动技术创新与落地应用。

目前距离 2024 全球 C++ 及系统软件技术大会召开仅剩 6 天，现在报名可享九折优惠，抓住最后 1 天优惠期，立即锁定席位！

来源：CSDN一点号