C++ 应该就是 C++

现代 C++ 的接受度

• 分歧很大：有些人觉得 C++20/23 带来了巨大的易用性提升（例如 optional、expected、filesystem、结构化绑定、if/switch 初始化、lambda），并且喜欢“现代 C++”。
• 另一些人，尤其是长期使用者，认为较新的标准过于繁复且令人不快，更偏好“带类的 C”或一个非常小的子集。
• 许多开发者事实上会把自己限制在项目特定的子集里，但在大型代码库中这更难做到，而且随着新特性（例如移动语义）引入更多样板代码或细微要求，这种情况更明显。

工具链、模块与依赖管理

• 普遍被认为是重大弱点：没有标准包管理器，也没有关于依赖、测试、日志等方面的集成方案。
• 模块被视为有前景，但由于编译器和工具支持不均衡，实际上几乎不可用。
• vcpkg 受到批评，原因包括行为脆弱、会改动源代码，以及版本固定到提交；Bazel/Buck 和 Nix/Guix 被提为部分解决方案。
• 有些团队只能把工具链提交进版本控制，或者给虚拟机做快照。

编译模型与性能

• 编译时间被视为最主要的痛点之一，往往比新的安全特性更优先。
• 讨论的原因包括：重复解析头文件、每个翻译单元都要实例化模板、链接器需要额外工作去消除重复，以及语法本身难以处理；大家对哪个因素占主导意见不一。
• 与 Go、Rust、Zig 和 C 的对比凸显出 C/C++ 的预处理和编译模型如何显得过时，即便使用了预编译头或模块也是如此。

内存安全、法规与语言方向

• 对于 C++ 用户到底有多要求内存安全存在分歧；有人说真正关心的人已经离开了，另一些人则认为很多人确实想要，但不想通过额外付费工具来实现。
• “折中式”安全（可选、覆盖不完整、需要运行时成本）被认为收益有限。
• 线程讨论了政府压力（NSA/CISA 指南、美国/欧盟待定规则）对内存安全语言的推动；虽然没有直接禁令，但预计采购和文书方面会有压力。
• 有人认为这篇文章是对 Rust 的防御性反应，而很多人把 Rust 视为系统编程中有竞争力的 C++ 替代品。

标准库、易用性与“零成本”

• 有人抱怨 std 缺少高性能原语（专用分配器、无锁/等待无锁结构、IPC、高性能线程），也没有针对游戏/数据库/操作系统级工作负载做优化。
• 另一些人认为这些应由外部库提供，而且不存在一种适用于所有工作负载的通用高性能设计。
• “零成本抽象”的理想受到质疑；隐藏的控制流（构造函数、析构函数、拷贝）以及异常如果使用不当或优化不佳，确实会带来成本。
• 像 std::print 这样的新 API 被认为比旧式用法（流）在自定义方面更笨重，进一步强化了对易用性差的印象。

通用性、历史包袱与替代方案

• 关于“被数百万人使用”是否能证明 C++ 是一门优秀的通用语言，展开了激烈争论；有人称这是一种谬误，另一些人则说它在现实世界中跨领域的广泛使用本身就是适用性的事实证据。
• 历史包袱和惯性被反复提及：许多人写 C++ 只是因为以前的代码就是这样；巨大的现有代码库使得破坏性变更或整体重写都不现实。
• 有人认为 C++ 应该继续把自己打造成最快的系统语言；也有人认为，考虑到它的历史和复杂性，与 Rust 或 Go 相比，它并不是新程序员的好选择。
• Carbon、cppfront 和“带模板的 C”等提案被提及为重新开始的尝试，但人们对其采用前景以及委员会作出激进破坏性变更的能力持怀疑态度。