关于C++的未来该向何处去，似乎有着很多争论甚至是激烈对抗。无论是Reddit上的小打小闹，还是官方C++标准委员会中的严肃讨论，都免不了要陷入立场之争、派系之争。这已经成为无法回避的客观现实。
C++的当前处境
就目前来看，C++阵营处于如下状态：C++的演进工作组（EWG）刚刚就采用P3466R0达成共识——即应当重新确认未来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++技术栈的团队，但绝不会是目前仍强行使用1998年古老预建库的团队。
当然，这在实践中会是一个渐变的过程。我只能想象，要想将大型技术代码库从可怕的混沌转化成具备一定可管理性、可构建性、经过lint分析、拥有正确版本控制的改良形态，必然要付出无数汗水、泪水、成本甚至是牺牲。
事后看来，我们当然可以轻飘飘地认为这一切都是历史大势的必然：谷歌等巨头的需求（即使用高度现代化的C++代码、建立自动化工具与测试以及现代化基础设施）明显与其（非常强烈的）向下兼容意愿之间存在脱节。
我们甚至可以大胆地讲，统一无方言的C++概念似乎在多年之前就已经消亡。目前我们至少面对着两条主要C++发展路线：
大家会注意到，两派最大的分歧并不在于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兼容性所导致的诸多麻烦和问题。
网友怎么看？
该帖子在Reddit社区中引发了诸多讨论。ID名为ravixp的Reddit用户对上述观点表示认同。
ID名为KittensInc的Reddit用户解释了美国禁止C++的合理性，因为美国政府认为C++代码库正成为负担，他们倡导避免重蹈覆辙以减少错误。缓冲区溢出等问题的预防变得重要，导致企业要求第三方审计以确保代码质量。企业面临现代化改造的抉择，否则可能面临倒闭风险，而采用现代开发实践的企业能更轻松应对。
但也有人认为，C++代码库的安全性不取决于其现代或遗留属性。90年代C++库注重安全性并多用运行时检查，而现代C++则减少运行时检查，将更多内容纳入类型系统，未定义行为用于优化。
“安全性的实现与C++代码库是现代还是“遗留”并无直接关联。事实上，在90年代，流行的C++库在开发时普遍注重安全性，并广泛采用了运行时检查来确保代码的正确执行。在当时，未定义行为并非被视为编译器可以对代码做出严格假设并执行激进优化的手段，而是被视为一种在不同平台和实现之间实现灵活性的合理方式。然而，进入21世纪初期，“现代”C++的发展方向发生了转变，决定减少运行时检查，并尝试将所有内容纳入类型系统中。对于那些无法通过静态验证的内容，它们被归类为未定义行为，编译器则可以根据优化需求进行自由处理。”
您是否在寻找一个能低成本、高效率完成模型精调的企业级大模型平台？
百度智能云千帆大模型平台限时推出特惠活动，为您提供一站式解决方案！
不仅支持免费训练，还提供部署推理3折优惠，更有热销模型资源包限时特惠