为什么STL的实现如此难以理解？ C++ 如何这里可以改进吗？
例如，为什么STL实现中的大多数成员都有_M_或_或__前缀？ 为什么有这么多样板代码？
C++ 缺少哪些功能可以使向量（例如）实现清晰且更简洁？
For instance why does most members in STL implementation have _M_ or _ or __ prefix?
Why there is so much boilerplate code ?
What features C++ is lacking that would allow make vector (for instance) implementation clear and more concise?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
实现使用以下划线开头的名称，后跟一个大写字母或两个下划线，以避免与用户定义的宏发生冲突。此类名称在 C++ 中是保留的。
例如，可以定义一个名为
Type的宏，然后定义一个名为#include的宏。如果vector实现使用Type作为模板参数名称，则会中断。但是，不允许定义名为
_Type（或__type、type__等）的宏。因此，vector可以安全地使用这样的名称。Implementations use names starting with an underscore followed by an uppercase letter or two underscores to avoid conflicts with user-defined macros. Such names are reserved in C++.
For example, one could define a macro called
Typeand then#include <vector>. Ifvectorimplementations usedTypeas a template parameter name, it would break.However, one is not allowed to define macros called
_Type(or__type,type__etc.). Therefore,vectorcan safely use such names.许多 STL 实现还包括检查调试版本，例如在比较两个迭代器时验证它们是否来自同一个容器，以及监视迭代器是否越界。这涉及相当复杂的代码来跟踪创建的每个迭代器的容器和有效性，但对于查找错误来说是无价的。该代码还与带有 #ifdefs 的标准发布代码交织在一起 - 即使在 STL 算法中也是如此。所以它永远不会像他们最基本的操作那么清晰。像这个这样的网站展示了STL算法的最基本功能，声明它们的功能是“相当于”他们显示的代码。但您不会在头文件中看到它。
Lots of STL implementations also include checking for debug builds, such as verifying that two iterators are from the same container when comparing them, and watching for iterators going out of bounds. This involves fairly complex code to track the container and validity of every iterator created, but is invaluable for finding bugs. This code is also all interwoven with the standard release code with #ifdefs - even in the STL algorithms. So it's never going to be as clear as their most basic operation. Sites like this one show the most basic functionality of STL algorithms, stating their functionality is "equivalent to" the code they show. You won't see that in your header files though.
除了 robson 和 AshleysBrain 已经给出的充分理由之外，C++ 标准库实现具有如此简洁的名称和紧凑的代码的原因之一是，几乎每个 C++ 程序（实际上是编译单元）都包含大量标准库头文件，并且因此，它们会被反复重新编译（请记住，它们主要是内联的和基于模板的，而 C 标准库头只包含少量函数声明）。按照“行业标准”风格指南编写的标准库将需要更长的时间来编译，从而导致特定编译器“慢”的感觉。通过最小化空格并使用短标识符名称，词法分析器和解析器要做的工作更少，并且整个编译过程完成得更快一些。
另一个值得一提的原因是，许多标准库实现（例如 Dinkumware、Rogue Wave（旧）等）可以与多种不同的编译器一起使用，这些编译器具有截然不同的标准合规性和怪癖。经常有很多宏黑客旨在满足每个受支持的平台。
In addition to the good reasons robson and AshleysBrain have already given, one reason that C++ standard library implementations have such terse names and compact code is that virtually every C++ program (compilation unit, really) includes a large number of the standard library headers, and they are thus repeatedly recompiled (remember that they're largely inlined and template-based, whereas the C standard library headers only contain a handful of function declarations). A standard library written to "industry standard" style guidelines would take longer to compile and thus lead to the perception that a particular compiler was "slow". By minimizing whitespace and using short identifier names, the lexer and parser have less work to do, and the whole compilation process completes a little bit faster.
Another reason worth mentioning is that many standard library implementations (e.g. Dinkumware, Rogue Wave (old), etc.) can be used with several different compilers with widely different standards compliance and quirks. There's frequently a lot of macro hackery aimed at satisfying each supported platform.