为什么 STL 实现如此难以理解？在这里如何改进 C++？答案

【问题标题】：Why STL implementation is so unreadable? How C++ could have been improved here?为什么 STL 实现如此难以理解？在这里如何改进 C++？
【发布时间】：2010-11-30 11:06:21
【问题描述】：

例如，为什么 STL 实现中的大多数成员都有 _M_ 或 _ 或 __ 前缀？为什么有这么多样板代码？

C++ 缺少哪些功能可以使向量（例如）实现更清晰、更简洁？

【问题讨论】：

你为什么要关心实现细节？
你会得到很多负面的 cmets，但我赞赏你愿意阅读代码并询问为什么它是这样编写的。太多的开发者不会尝试，也不会在意。
@Łukasz Lew：很高兴您阅读了代码！一旦你阅读了一定数量的代码，突然之间，STL 实现不再是不可读的，变得清晰而明显。
当文档未能为您提供详细信息时，这是因为详细信息可能会发生变化。所以这不是阅读源代码的好理由。您在源代码中找到但未在文档中找到的任何内容都可能在下一个编译器版本中更改，因此您不应依赖它。
@Pavel：确实发生了。我已经阅读了一整天的代码，现在它很容易阅读。此外，我还学习了一些不错的 C++ 习惯用法和模式。了解了分配器的具体工作原理、如何使用高级迭代器获得可读代码等等！

标签： c++ stl c++11 readability

【解决方案1】：

实现使用以下划线开头的名称，后跟一个大写字母或两个下划线，以避免与用户定义的宏发生冲突。这些名称在 C++ 中是保留的。例如，可以定义一个名为Type 的宏，然后是#include <vector>。如果vector 实现使用Type 作为模板参数名称，它会中断。但是，不允许定义名为_Type（或__type、type__ 等）的宏。因此，vector 可以安全地使用此类名称。

【讨论】：

+1 确实。 GCC 的实现甚至包含一个注释，解释了为什么队列的底层容器被称为 c 并且没有“按照样式指南进行丑化”。
所以 C++ 可以通过使宏系统更强大来改进:)
这仍然不能防止命名不当的用户定义宏与类型或成员函数的名称冲突（例如#define size 2）。

【解决方案2】：

除了 robson 和 AshleysBrain 已经给出的充分理由之外，C++ 标准库实现具有如此简洁的名称和紧凑代码的一个原因是几乎每个 C++ 程序（实际上是编译单元）都包含大量标准库头文件，因此它们被反复重新编译（请记住，它们主要是内联的和基于模板的，而 C 标准库头文件只包含少数函数声明）。按照“行业标准”风格指南编写的标准库将需要更长的时间来编译，从而导致特定编译器“慢”的感觉。通过最小化空格和使用短标识符名称，词法分析器和解析器要做的工作更少，整个编译过程完成得更快。

另一个值得一提的原因是，许多标准库实现（例如 Dinkumware、Rogue Wave（旧）等）可以与几种不同的编译器一起使用，这些编译器具有截然不同的标准合规性和怪癖。经常有很多宏骇客旨在满足每个受支持的平台。

【讨论】：

【解决方案3】：

许多 STL 实现还包括检查调试版本，例如在比较两个迭代器时验证它们是否来自同一个容器，并观察迭代器是否越界。这涉及到相当复杂的代码来跟踪创建的每个迭代器的容器和有效性，但对于发现错误是非常宝贵的。该代码还与带有#ifdefs 的标准发布代码交织在一起——即使在STL 算法中也是如此。所以它永远不会像他们最基本的操作那样清晰。 this one 之类的网站展示了 STL 算法的最基本功能，称它们的功能“等同于”它们展示的代码。但是，您不会在头文件中看到它。

【讨论】：