正统 C++（2016）

对“Orthodox C++”的总体反应

• 许多人认为这篇文章过于肤浅或教条：它只是列出禁令，却没有给出细致的指导或理由。
• 也有人，尤其是来自游戏/嵌入式背景的人，表示它在很大程度上反映了长期以来务实的实践：使用小子集、不用 RTTI/异常、限制 stdlib。
• 还有几条评论指出，C++ 本来就是多范式语言，每个认真做项目的团队早已在选择自己的子集；“orthodox”不过是又一种风格。

C 与 C++ 以及语言复杂性

• 一些 C 程序员认为 C++ 带来了沉重的心智负担：更多隐藏行为、生命周期规则，以及比 C 更多的“地雷”。
• 另一些人反驳说，C 本身就有大量隐藏复杂性和未定义行为；C++ 至少提供了更强的类型系统和更好的抽象。
• 一个反复出现的主题是：工程师都在忙着解决领域问题，不想去追踪 C++ 的每一个新特性或版本变化。

现代特性：auto、范围 for、RTTI、异常

• 基于范围的 for 配合 auto 被广泛认为可读性高，也比迭代器样板代码更不容易出错。
• 批评者说 auto 会在代码审查和 diff 中掩盖类型；支持者则回应说，类型推断在许多语言里都很常见，而且 IDE 已经能解决这个问题。
• 禁用 RTTI 和 dynamic_cast 被一些人视为没必要；另一些人则把它称为代码异味，更喜欢手写或自定义 RTTI，以获得性能/控制。
• 异常是最具争议的话题：
  • 反异常阵营认为它不可预测、难以调试、影响确定性，而且“这个函数会抛什么”这类契约并不清晰。
  • 支持异常的人强调：只要把它们用于真正异常的契约违背，而不是日常错误处理，就完全没问题。

标准库、容器与 I/O

• 对 std::map、std::unordered_map、std::deque，甚至 std::vector 的批评很强：涉及性能、缓存行为、并发以及 API 别扭。
• 也有人认为它们在海量真实世界代码中完全够用；问题主要出现在极端高吞吐/低延迟场景。
• iostreams 普遍不受欢迎；很多人更喜欢 C 风格的 printf，或更新的 fmt/<format> API。有人认为，避免 iostream 但仍使用类型安全的格式化，是理智的中间路线。

模板元编程与替代方案

• 一些人赞赏重度模板元编程和函数式风格，认为它们独具威力，尤其是在较新的 constexpr/consteval/concepts 加持下。
• 另一些人抱怨编译时间和难以阅读的错误信息，主张谨慎使用。
• Rust、Zig、Nim、D，以及“更好的 C”式方案也被反复提及；当有选择时，一些人表示他们会完全避开 C++。