C++ 分裂：现代工具链与遗留代码的战争
The Two Factions of C++
C++ 社区正面临深刻的分裂。一方面，以 Google 为代表的现代科技公司拥有强大的自动化重构工具，能够轻松管理数亿行代码并推动语言演进；另一方面，大量遗留项目受困于无法从源码构建的老旧环境，导致任何破坏 ABI 的改进都举步维艰。C++ 标准委员会为了兼容后者，坚持零开销原则和向后兼容，却可能正在牺牲语言的未来。随着 Microsoft 重写核心库、美国政府部门呼吁弃用内存不安全语言，以及 Herb Sutter 的离职，C++ 似乎正陷入“无法改变”的僵局。这场冲突的本质并非语言本身，而是工具链能力的巨大鸿沟。
数十年的经验一致表明，拥有大型代码库的客户无法也不会为了遵守严格规则而修改哪怕 1% 的代码行，除非监管要求迫使他们这样做。
HN 评论区
78- YuechenLi
从目前的阅读来看（还没读完文章，但感觉讲的是当时刚刚发生的事件），标题应该加上 (2024) 的标注。
另外，当时 HN 对此事的报道在这里：https://news.ycombinator.com/item?id=42231489
- tonyedgecombe
> 至少这是一种苦涩的认知：业界根本不在乎重构现有代码
重构工作？经过充分测试的代码？？？
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- tialaramex
这是一份非常有意思的事实与引语总结，并得出了结论。我认为实际上派系不止文中提到的两个。就我个人而言，C++98 和 Qt5 就能胜任所有用途，而且运行良好；而此后的 C++ 变成了一个不断移动的目标，编译器之间充满了不兼容性。一味追逐语言和编译器的最新版本既昂贵又令人精疲力竭。我更喜欢 Ada 社区解决这个问题的方式：他们从容地制定新标准版本，在此之前，大多数编译器厂商早已更新了产品，而且在新标准正式通过之前，大家就已经对新特性有了丰富的实践经验。在计算机科学领域，似乎有一条自然法则：不断“改进”好东西，直到它们变得无法使用，人们纷纷离去。在 C++ 领域我就是这么做的；我有几个 C++11 代码库（其中一些是从更新版本回退的），但大多数都是 C++98/03；我甚至 fork 了一个 Qt5 版本（LeanQt），搭配我自己构建的系统（BUSY），这样维护起来比不断追逐不同平台间的新编译器/工具不兼容性要轻松得多。