Sane C++ 库

原文 ↗ Hacker News 讨论 ↗

一个名为“Sane C++ Libraries”的新项目旨在为 C++ 提供一个轻量、无需 STL 的替代生态系统，强调更快的编译时间、更简单的抽象，以及异步 I/O、JSON 和反射等实用工具。评论者意见分歧：一些人欢迎其对极简主义、显式错误处理，以及避免异常、RTTI 和智能指针的专注；另一些人则认为避开标准库只会加剧碎片化，并牺牲成熟、优化良好的组件。这场讨论凸显了 C++ 中长期存在的张力：性能、简洁性、可移植性，与依赖标准库还是自定义或第三方基础之间的取舍。

总体目标与定位

  • 该库旨在构建一个“替代性的 C++ 世界”，更像 Python/Node/Zig/C：实用功能、异步 I/O、平台抽象、更小的二进制体积、无异常/RTTI/stdlib。
  • 作者强调趣味性、简洁性，以及聚焦“95% 的用例”，而不是覆盖每一个边缘情况。
  • 有些人将其视为安全性较差的 C 与臃肿的 libstdc++ 之间的中间地带；另一些人则认为“没有 stdlib / 没有异常 / 自定义原子操作”本身就谈不上“sane”。

避免使用 stdlib 与生态碎片化

  • 一些评论者反对忽略 STL，认为这只会保证更多碎片化和更差的互操作性；他们已经在为每个 C++ 库都定义自己的 String/Vector 类型而苦恼。
  • 也有人认为 STL 带有设计与兼容性包袱（例如 vector<bool>、标准 map、std::regex、沉重的模板、缓慢的调试构建），而且许多严肃项目本来就会自己实现核心库。
  • 与 Abseil 的比较：Abseil 是对 STL 的补充，而这个项目则是有意替换其中的大部分。

容器、算法与数据结构

  • 当前的容器集合被认为不完整；缺少类似标准库的 set、queue、deque 和 hash map，对一些人来说是阻碍。
  • 一些用户高度依赖 stack/deque；作者对 deque 持怀疑态度，更偏好基于 vector 的方案和 arena 风格的容器。
  • “算法”库目前把 bubbleSort 放在最前面；这引发了批评，作者澄清这只是占位符，之后会逐步扩展。

内存管理、智能指针与异常

  • 该项目有意不提供 SharedPtr/UniquePtr，其原则是反对大量微小堆对象以及不清晰/共享的所有权。
  • 一些人强烈不同意，希望所有堆对象都使用智能指针，并将其视为零开销或低开销的安全工具。
  • 另一些人则描述了使用 vector/arena、句柄和清晰所有权分组来替代智能指针的模式。
  • 更大的争论：许多评论者为无异常 C++（通常使用 ErrorOr 风格类型）辩护，认为这很常见也很实用；而另一些人坚持认为 C++ 在任何有意义的层面上都不可能“无异常”，认为所有错误处理本质上都是“伪装的异常”。
  • 对 C++ 异常的担忧包括非零开销、RTTI、隐藏控制流、从函数签名看不出是否会抛出，以及鼓励“只写成功路径”代码。

原子操作与底层问题

  • 自定义原子操作受到质疑，因为 std::atomic 与 C++ 内存模型深度绑定。
  • 不使用 stdlib 是眼下的直接原因；作者暗示未来可能提供一个可选标志，在可用时使用标准头文件。

构建系统与宏

  • 用 C++ 描述构建被批评为不“sane”；支持声明式方案的人认为其可扩展且更简单。
  • 作者反驳说，流行的“声明式”工具（例如 CMake）其实本质上也是命令式 DSL。
  • 有些人不喜欢该项目使用宏，认为这不够“sane”；作者指出大多数宏都是平台切换，reflection 中的宏则是可选的。