一篇主张少用 C++ 的 C++ 文章，最反常的地方是：到 2025 年，它才把 C++20 放进“可以选择性使用”的范围。
Branimir Karadžić 的《Orthodox C++》说得很直接：C++ 可以用，但别把所谓 Modern C++ 的整套复杂性搬进来。用 C++ 改善 C。能少一层运行时、少一层构建麻烦、少一种团队方言，就少一层。
这篇文章值得看，不是因为它给了 C++ 新答案。恰好相反，它提醒工程团队：很多时候，答案是少用一点。
Orthodox C++ 到底禁什么
Orthodox C++ 不是官方标准，也不是 C++ 社区共识。它是一套工程风格：保留 C++ 对 C 的改进，但主动避开不必要的现代特性。
它更适合几类项目：代码寿命长、平台多、性能敏感、工具链复杂。比如大型代码库、游戏引擎、嵌入式、跨平台底层库。
| 项目 | Orthodox C++ 的态度 | 主要理由 |
|---|---|---|
| exceptions | 尽量不用 | 错误处理路径不够直观，也可能带来运行时和优化约束 |
| RTTI | 不用 | 增加运行时依赖，类型关系更难保持简单 |
| iostream | 不用 | 倾向 printf 风格，少一层复杂抽象 |
| 会分配内存的 STL | 慎用 | 内存分配不可控时，代价会在游戏和嵌入式里放大 |
| 过度模板元编程 | 避免 | 编译时间、可读性、调试成本容易失控 |
| modules | 保守 | 构建系统、工具链、平台兼容还要一起买单 |
| 新 C++ 标准 | 等一等 | 标准发布后约 5 年，再选择性采用 |
这个“五年规则”很关键。它不是反技术进步，而是反抢跑。
C++11 可以等到 2016 年后再认真评估。C++20 到 2025 年再选择性使用。这个节奏听起来慢，但对跨平台工程很现实：编译器、系统发行版、CI、构建工具、团队经验，都需要时间对齐。
作者还讽刺过一种做法：2016 年就要求开源项目必须使用 C++17，这不是工程判断，而是 Resume Driven Development，履历驱动开发。
这句话不好听，但很准。代码还没服务用户，先服务简历。
它反对的不是 C++，是特性崇拜
Stroustrup 有句常被引用的话：Within C++, there is a much smaller and cleaner language struggling to get out。C++ 里面有一门更小、更干净的语言，正在挣扎着出来。
Orthodox C++ 基本就是把这句话写进工程纪律。
我不认为它证明了“现代 C++ 全错”。异常、RTTI、STL、modules 都有合理场景。业务系统、库代码、工具链项目，可能确实需要这些能力。
问题出在边界。
一个人喜欢异常，一个人坚持返回码。一个人用模板写编译期迷宫，一个人只想 grep 调用链。一个库要求新编译器，一个平台还卡在旧工具链。
每个选择单看都有理由。合起来，就是维护税。
对 C/C++ 工程师，这件事的动作很具体：少把“我会用某个新特性”当成默认加分项。先看项目约束。能不能跨编译器构建，能不能被同事读懂，能不能在五年后继续改。
对技术负责人，动作更硬：把团队认可的 C++ 子集写进编码规范。明确哪些特性能用，哪些要审批，哪些平台必须支持。不要让每个模块自带一套语言哲学。
| 角色 | 该怎么取舍 |
|---|---|
| C/C++ 工程师 | 新特性先问三件事：是否降低复杂度，是否影响构建，是否让错误路径更清楚 |
| 技术负责人 | 制定项目级语言子集，锁定工具链支持矩阵，避免团队写出多种 C++ 方言 |
| 游戏、嵌入式、跨平台团队 | 慎用隐式分配、复杂运行时和过新标准，优先保证可控、可移植、可维护 |
这里的限制也要说清。Orthodox C++ 不是万能药。
如果团队做的是现代应用层服务，平台统一，工具链更新快，开发者也熟悉现代 C++，完全可以采用更多标准库和语言特性。保守本身不自动等于专业。把所有现代特性一刀切，也可能变成另一种偷懒。
关键不是“新”或“旧”。关键是成本有没有被看见。
接下来要看三件事
工具越强，越考验克制。
C++ 的麻烦在于，它给了团队太多选择。选择多不是坏事，但没有治理时，选择会变成分裂。语言复杂度最后会落到构建系统、代码审查、调试路径、招聘培训和长期维护上。
早期铁路也有类似问题。轨道越铺越远，车越跑越快，但轨距、调度、维护标准一乱，速度本身就会制造事故。不完全一样，但结构相似：能力扩张之后，治理跟不上，复杂性就开始收费。
看 Orthodox C++，别只看口号。接下来真正该观察的是三件事。
| 变量 | 为什么重要 |
|---|---|
| 工具链成熟度 | 新标准能不能被目标平台稳定支持，决定它是不是工程资产 |
| 构建和调试成本 | modules、模板、库依赖如果拖慢反馈周期，收益会被吃掉 |
| 团队一致性 | 特性本身不可怕，可怕的是每个人按自己的偏好写一套规则 |
这也是我最认可 Orthodox C++ 的地方。它没有把所有现代 C++ 都打成坏东西。它只是把一句工程老话重新摆到桌面上：复杂性不是免费午餐。
2025 年选择性接受 C++20，反而说明它不是闭眼怀旧。它的逻辑一直是：等编译器、系统、构建工具、团队经验过了磨合期，再拿真正有用的部分。
慢，不一定落后。有时只是知道谁来付账。
一篇主张少用 C++ 的 C++ 文章能长期被讨论，原因也在这里。很多团队已经尝到过特性膨胀的后果：语法更现代，维护更古早；模型看着更强，产品反而更虚。
Orthodox C++ 不必被奉为正统。它真正有用的地方，是逼团队回答一个问题：你是在用语言降低成本，还是在用语言制造一种看起来很高级的债务？