关于 C++ 的未来该向何处去，似乎有着很多争论甚至是激烈对抗。无论是 Reddit 上的小打小闹，还是官方 C++ 标准委员会中的严肃讨论，都免不了要陷入立场之争、派系之争。这已经成为无法回避的客观现实。
C++ 的当前处境
目前来看，C++ 阵营处于如下状态：C++ 的演进工作组（EWG）刚刚就采用 P3466 R0 达成共识——即应当重新确认未来 C++ 演进的设计原则：
这意味着拒绝 ABI 破坏，保留与 C 以及此前 C++ 的链接兼容性。
这也意味着拒绝“病毒注释”（例如不设全生命周期注释）。
这大大强调了对一系列不兼容目标的处置，即拒绝 ABI 破坏以及零开销原则。
无论是好是坏，这都是对当前 C++ 语言演进轨迹的强化。
但与此同时，在 C++ 的发展道路上也面临着一系列阻碍，包括美国政府机构（网络安全与基础设施安全局（CISA）、美国国家安全局（NSA）以及白宫）希望人们停止使用 C++，美国政府各个部门均已发布文件、报告和建议，警告技术行业不要使用内存不安全的语言。
各大科技巨头也有弃 C++ 转投入 Rust 之势。
不久前，在微软工作了 22 年的 ISO C++ 委员会主席 Herb Sutter 也离开了微软，成为 Citadel Securities 的技术研究员。有消息称微软明显正在使用 Rust 重写其核心库。早在 2022 年，Microsoft Azure 首席技术官 Mark Russinovich 就敦促科技行业放弃 C/C++。“说到语言，现在是时候停止用 C/C++ 启动任何新项目，并在需要非语言的场景中使用 Rust，”他说。“为了安全和可靠性，行业应该宣布这些语言已弃用。”
谷歌曾在 2021 年就发文称正在全力推动 Rust。谷歌表示：“Android 平台代码的正确性是每个 Android 版本安全性、稳定性和质量的首要任务。C 和 C++ 中的内存安全错误仍然是最难解决的错误来源。我们投入了大量的精力和资源来检测、修复和缓解此类错误，这些努力有效地防止了大量错误进入 Android 版本。然而，尽管付出了这些努力，内存安全错误仍然是稳定性问题的主要因素，并且始终占 Android 高严重性安全漏洞的 70% 左右。而 Rust 通过结合使用编译时检查来强制执行对象生存期 / 所有权，并使用运行时检查来确保内存访问有效，从而提供内存安全保障。在提供与 C 和 C++ 相当的性能的同时，还实现了这种安全性。” 实际上已经开始开发 C++/Rust 双向互操作工具。
工具地址：https://github.com/google/crubit
AWS 也正在重度使用 Rust。AWS 在官微上发文称，“Rust 带来了完善的工具、强大的包管理器 (Cargo)，也许最重要的是——一个快速增长且充满热情的开发者社区。随着 Rust 越来越受欢迎，越来越多的知名组织，包括 AWS，将其用于性能和安全性是首要关注点的关键应用程序。例如，Amazon S3 利用 Rust 尝试以个位数毫秒的延迟返回响应。用 Rust 编写的 AWS 产品组件还包括 Amazon CloudFront、Amazon EC2 和 AWS Lambda 等。
此外，臭名昭著的 Prague ABI 投票已经开始（即「C++23 不会破坏 ABI，但不清楚未来是否变化」）。据称谷歌大幅降低了其在 C++ 开发流程中的参与度，转而开发自己的 C++ 后继语言。他们甚至专门发布总结，概述了在尝试改进 C++ 时遇到的所有问题。这也为 C++ 风雨飘摇的未来多蒙上一层阴影。
多年以来，人们竭尽全力参与 C++ 标准委员会流程，但却最终被彻底驳回的故事已经广为人知，并在整个社区中流传。（哪怕是已经在 C 中得到实现的功能也不例外。）模块设计仍未实现，C++ 什么时候才能拥抱模块化？
基于以上种种，不免让人对 C++ 的未来表示担忧。事实上，很多人对 C++ 委员会对于混乱现状的掌控能力已经失去了信心。
困在两种文化冲突之中
人们似乎正在寻求其他解决方案。
比如谷歌自 ABI 投票以来，就明显对 C++ 委员会的“流程”失去了信心。这并不是对语言本身失去信心，毕竟谷歌拥有世界上最大的 C++ 代码库之一，而且一直为其提供着非常好的维护服务。所谓失去信心，主要是不看好该语言在面对来自不同角度的压力（包括潜在政府法规、竞争语言的冲击、关键参与者对于更高性能以及更佳安全保障的规划等）时能否保持住不断演进的能力。
那么问题的根源是什么？C++ 为什么会变得这么……食古不化？
这个问题并不难回答，只消看看 Herb Sutter 在他关于配置文件的文章就能窥得一二：
“我们必须尽量减少对现有代码的变更需求。对于现有代码中已经存在的应用，数十年的经验一直表明，大多数拥有大型代码库的客户不能、也不会为了满足严苛规则而更改哪怕1%的代码行。除非监管要求强迫他们这样做，否则即使是出于安全原因也无法推动这方面举措。”
——Herb Sutter
这话说得……但神奇的是，人们似乎又对此见怪不怪。
现在让我们跟 WG21 成员页面上 Chandler Carruth 的小记做一番对比：
“我执掌了基于 Clang 构建的 C++ 工具与自动重构系统的设计工作，其现在属于 Clang 项目的组成部分……在谷歌内部，我领导了将基于 Clang 的自动重构工具扩展到我们整个代码库（共涉及超过 1 亿行 C++ 代码）的努力。我们可以在 20 分钟之内分析并对整个代码库执行重构。”
看到了吗，人家好像愿意做变更。
而遗憾的是，自动化迁移工具也是 C++ 阵营目前唯一拿得出手的应用案例了。
基本上，我们看到了两大截然不同的 C++ 用户派系之间的冲突：
相信未来一定会出现一支能够优雅处理迁移，并且立足版本化源代码构建其 C++ 技术栈的团队，但绝不会是目前仍强行使用 1998 年古老预建库的团队。
当然，这在实践中会是一个渐变的过程。我只能想象，要想将大型技术代码库从可怕的混沌转化成具备一定可管理性、可构建性、经过 lint 分析、拥有正确版本控制的改良形态，必然要付出无数汗水、泪水、成本甚至是牺牲。
事后看来，我们当然可以轻飘飘地认为这一切都是历史大势的必然：谷歌等巨头的需求（即使用高度现代化的 C++ 代码、建立自动化工具与测试以及现代化基础设施）明显与其（非常强烈的）向下兼容意愿之间存在脱节。
我们甚至可以大胆地讲，统一无方言的 C++ 概念似乎在多年之前就已经消亡。目前我们至少面对着两条主要 C++ 发展路线：
任何稍微现代的 C++，可能至少是从 C++17 开始。它们支持 uniqe_ptr, constexpr, lambdas 还有 optional。一切都可以从版本化的源代码构建，使用某种专用、干净且统一的构建流程，该流程至少要比原始 CMake 稍微复杂一些，而且只要认真观察应该就能顺利起效。其还具备某种静态分析器、格式化程序、linter 等。总之，要支持一切有助于保持代码库干净和现代的协议。
不符合以上特征的其他产物。比如那些长期运行在中等规模银行里那古老、布满灰尘的服务器当中的 C++ 项目。这些 C++ 往往依赖于某些极其陈旧的编译代码块，而且对应的源代码已经丢失，且无法联系到其原始作者。还包括一切部署在微型服务器上的 C++，要在其他环境下正常启动，工程师们往往需要一个月时间才能厘清其中的所有隐式依赖项、配置和环境变量。这些就是被广泛归类为成本中心的遗留代码库。
大家会注意到，两派最大的分歧并不在于 C++ 本身，而在于依托工具或者其他手段以干净且定义明确的方式，立足版本化源代码进行构建的能力。理想情况下，我们甚至并不需要记住前一个人设置的标记或者环境变更，即可顺畅部署而不致引发崩溃。
很多人会强调，这类生态工具并不在 C++ 标准委员会的职责范围之内。这话也没错，但工具之所以不在他们的职责范围内，是因为 C++ 标准委员会放弃了这份责任（他们只专注于 C++ 语言的规范，而非具体实现）。当然，这跟 C++ 语言本身的设计有关，属于遗留问题，我们也不能过多责怪。总之如今的 C++ 已经成为一套用于统一不同实现的囊括性标准。
但相比之下，如果要说 Go 有哪件事做得最为正确，那就是它证明了工具非常重要。相比之下，C++ 就像是来自史前时代、来自 linter 被发明出来之前。C++ 没有统一的构建系统，甚至没有勉强能算统一的包管理系统，因此解析和分析起来都极其困难（这对配套工具来说很糟糕），每一次更改都会带来一场艰苦卓绝的折磨和对抗。
这两个派系之间还存在着巨大且仍在不断恶化的裂痕。老实说，我认为这种裂痕不可能很快消失。C++ 委员会似乎致力于（当然，这已经是很高情商的说法了）保持向下兼容性，甚至愿意为此不计成本。
后果是什么？
于是配置文件机制就成了现在这个样子：安全配置文件的意义并不在于帮助已经迈向现代、精通开发技术的 C++ 企业解决问题，它们的目标是在实现改进的同时，保证无需对旧有代码做出任何更改。
模块机制也是如此，开发者应该可以“仅”将 header 文件作为模块导入，且不致因此引发任何类型的向下兼容性问题。
当然，人人都希望那种可以直接插入即生效，且无需对旧有代码做出任何更改的功能。但很明显，这些功能的设计（也是最重要的特征）是以“遗留 C++ 代码”为目标的。而任何需要对遗留 C++ 进行功能迁移的演进在 C++ 委员会都完全行不通，毕竟正如 Herb Sutter 所说，绝对不能指望人们愿意承担这份迁移负担。
这就是我在查阅 C++ 讨论资料时最鲜明的印象：阵营中分为两大派系，一派是现代 C++，另一派则是遗留 C++。两大派系之间存在着激烈分歧，而许多文章都只针对其中某一特定群体的需求撰写而成。
C++ 委员会正试图防止这种分歧进一步扩大。可能也正因为如此，Sean Baxter 在 Safe C++ 方向上做出的任何尝试都注定徒劳无功。这将是一波颠覆性的变革，可能会创造一种全新的 C++ 编写方式，可惜变不得。
当然，这里还有另外一个问题，就是可能某位 C++ 标准委员会成员特别特别固执，不接受任何贡献者在发展取向上的异见。
我绝不是要指责任何人，但我曾经多次听说 C++ 委员会搞双重标准，比如“如果您希望该提案获得批准，希望您能在几款工作编译器上进行全面、有效的实现，但我们仍乐于支持某些未经有效概念验证的大型项目（例如模块和配置文件机制）。”
如果情况继续发展下去，那么我严重怀疑 C++ 阵营的彻底分裂恐怕就在眼前。
而这一切，甚至还没算上破坏 ABI 兼容性所导致的诸多麻烦和问题。
如果大家对此持怀疑态度，也可以将其理解为对于 Rust“全生命周期注释”和 Sean Baxter“Safe C++”提案的明确否定。哪怕更乐观地看，这也至少代表着该委员会根本不关心对现有代码的重构需求。︎
“你不会为自己不用的东西付费。”本质上，现有 C++ 功能只在我们积极使用时才会影响到运行时性能。而这显然跟稳定的 ABI 有所抵触，毕竟稳定 ABI（大家可以将其理解为 C++ 中的一项特性）会排除某些性能改进措施。
我认为 Carbon 比大多数人印象中要有趣得多。后续我可能会撰写一篇专门的讨论文章。
那么 C++ 阵营真的在分崩离析吗？这要看从哪个角度理解。如果从 C++ 代码存续的角度看，那么并不会，至少原有的 C++ 成果还将长期存在。
请注意，我说的是 C++ 阵营本身，与之对应的各种不同编译器以及编译扩展完全是另一个概念。
网友怎么看？
该帖子在 Reddit 社区中引发了诸多讨论。ID 名为 ravixp 的 Reddit 用户对上述观点表示认同。
“这段话引发了我的强烈共鸣，原因是我曾亲眼见证了一个庞大的 C++ 代码库，在历经数十年的开发过程中，如何从“传统”逐步过渡到“现代”C++。这一转型并非一蹴而就，而是由不同团队在不同时间和以不同速度独立决定的，至今仍在持续进行中。任何新的代码现代化计划都不得不面对这样一个现实：代码库中的各个部分起始的现代化水平参差不齐。
（试想，在一个同时充斥着 std::string、C 风格字符串以及源自 20 年前、因当时 STL 尚不完善而自创的字符串类型的代码库中，引入静态分析将是一项多么艰巨的任务！）
然而，现代化的代价高昂。这里所指的现代 C++，并不仅仅是编写方式上的差异，它还意味着可能需要重建整个工具链上层结构，以使代码符合现代标准，并拥有一支能够紧跟 C++ 发展步伐的工程团队。重要的是要认识到，这里的冲突并非源于对传统 C++ 与现代 C++ 的个人偏好之争，而是关乎能否承担得起现代 C++ 转型的成本。C++ 确实需要变革，但真正的挑战在于我们共同能够承受多大的变革，以及如何在有限的投入中获得最大的价值回报。
ID 名为 KittensInc 的 Reddit 用户解释了美国禁止 C++ 的合理性，因为美国政府认为 C++ 代码库正成为负担，他们倡导避免重蹈覆辙以减少错误。缓冲区溢出等问题的预防变得重要，导致企业要求第三方审计以确保代码质量。企业面临现代化改造的抉择，否则可能面临倒闭风险，而采用现代开发实践的企业能更轻松应对。
“我并不惊讶于未来几年这种动态可能会发生变化。遗留的 C++ 代码库正迅速成为一项沉重的负担。美国政府已经认识到，通过采取不同的设计决策可以有效避免一类错误的发生，并正在积极倡导避免重蹈覆辙。我认为，相关责任人只是时间问题，他们终将跟上这一变革的步伐。
如果我们认为缓冲区溢出等问题是完全可以预防的，那么当这类问题成为安全事件的根源时，黑客攻击、勒索软件、数据泄露的保险拒赔也将变得合乎逻辑。在这种背景下，企业会愈发要求软件供应商提供第三方代码库的 linting 审计，以确保代码质量。
我们已经到了一个十字路口，不进行现代化改造的代价将变得无法承受。对于代码库而言，要么进行现代化改造以适应新时代的需求，要么面临公司倒闭的风险。那些采用现代开发实践的企业，只需借助一些简单的分析工具并完成必要的文档填写，就能轻松应对；而那些缺乏有效工具、且技术债务在代码库中不断累积的企业，将面临严重的困境。”
但也有人认为，C++ 代码库的安全性不取决于其现代或遗留属性。90 年代 C++ 库注重安全性并多用运行时检查，而现代 C++ 则减少运行时检查，将更多内容纳入类型系统，未定义行为用于优化。
“安全性的实现与 C++ 代码库是现代还是“遗留”并无直接关联。事实上，在 90 年代，流行的 C++ 库在开发时普遍注重安全性，并广泛采用了运行时检查来确保代码的正确执行。在当时，未定义行为并非被视为编译器可以对代码做出严格假设并执行激进优化的手段，而是被视为一种在不同平台和实现之间实现灵活性的合理方式。
然而，进入 21 世纪初期，“现代”C++ 的发展方向发生了转变，决定减少运行时检查，并尝试将所有内容纳入类型系统中。对于那些无法通过静态验证的内容，它们被归类为未定义行为，编译器则可以根据优化需求进行自由处理。”
原文链接：
https://herecomesthemoon.net/2024/11/two-factions-of-cpp/
