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

Question

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

C ++缺少哪些功能可以让make vector（例如）实现更清晰，更简洁？

Answer 1

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

Answer 2

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

Answer 3

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

值得一提的另一个原因是许多标准库实现（例如Dinkumware，Rogue Wave（旧）等）可以与几个不同的编译器一起使用，这些编译器具有广泛不同的标准兼容性和怪癖。经常有许多宏观hackery旨在满足每个支持的平台。