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