为什么大多数 STL 实现中的代码如此复杂？

Question

STL 是 C++ 世界的重要组成部分，大多数实现都源自 Stepanov 和 Musser 的最初努力。

我的问题是考虑到代码的重要性，它是人们出于敬畏和学习目的查看编写良好的 C++ 示例的主要来源之一：为什么 STL 的各种实现看起来如此令人厌恶 - 令人费解且通常都是很好的例子，说明如何不从美学的角度编写 C++ 代码。

下面的代码示例不会在我工作过的地方通过代码审查，原因包括变量命名、布局、宏和运算符的使用，这些需要不仅仅是简单的一瞥才能弄清楚实际发生的情况。

template<class _BidIt> inline
bool _Next_permutation(_BidIt _First, _BidIt _Last)
{  // permute and test for pure ascending, using operator<
_BidIt _Next = _Last;
if (_First == _Last || _First == --_Next)
   return (false);

for (; ; )
   {  // find rightmost element smaller than successor
   _BidIt _Next1 = _Next;
   if (_DEBUG_LT(*--_Next, *_Next1))
      {  // swap with rightmost element that's smaller, flip suffix
      _BidIt _Mid = _Last;
      for (; !_DEBUG_LT(*_Next, *--_Mid); )
         ;
      _STD iter_swap(_Next, _Mid);
      _STD reverse(_Next1, _Last);
      return (true);
      }

   if (_Next == _First)
      {  // pure descending, flip all
      _STD reverse(_First, _Last);
      return (false);
      }
   }
}


_Ty operator()()
   {  // return next value
   static _Ty _Zero = 0;   // to quiet diagnostics
   _Ty _Divisor = (_Ty)_Mx;

   _Prev = _Mx ? ((_Ity)_Ax * _Prev + (_Ty)_Cx) % _Divisor
      : ((_Ity)_Ax * _Prev + (_Ty)_Cx);
   if (_Prev < _Zero)
      _Prev += (_Ty)_Mx;
   return (_Prev);
   }

请注意，我并不是在批评该界面，因为它设计得非常好并且适用。我关心的是实现细节的可读性。

之前曾提出过类似的问题：

是否有一个可读的实现STL的

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

注意：上面提供的代码取自 MSVC 2010 算法和队列头。

Answer 1

关于变量名称，库实现者必须使用“疯狂”的命名约定，例如以下划线开头的名称，后跟大写字母，因为这样的名称是为它们保留的。它们不能使用“正常”名称，因为这些名称可能已由用户宏重新定义。

第 17.6.3.3.2 节“全局名称”§1 规定：

某些名称和函数签名集始终保留给实现：

• 每个包含双下划线或以下划线开头后跟大写字母的名称都保留给实现以供任何使用。

• 每个以下划线开头的名称都保留给实现，以用作全局命名空间中的名称。

（请注意，这些规则禁止像我经常看到的 __MY_FILE_H 这样的标头保护。）

Answer 2

Neil Butterworth，现在被列为“匿名”，在他对 SO 问题的回答中提供了一个有用的链接“是否有 STL 的可读实现？”。引用他的回答：

有一本书《C++ 标准》
模板库，由
最初的STL设计师Stepanov &李
（与 PJ Plauger 和 David
Musser），它描述了一种可能的
实现，完整代码 -
看
http://www.amazon.co.uk/C-标准模板库/dp/0134376331。

另请参阅该线程中的其他答案。

无论如何，大多数 STL 代码（我在这里所说的 STL 是指 C++ 标准库的类似 STL 的子集）是模板代码，因此必须是仅头文件，并且由于几乎每个程序都使用它，所以拥有它是值得的代码尽可能短。

因此，简洁性和可读性之间的自然权衡点在简洁性方面比“正常”代码要远得多。

此外，标准库是将应用程序代码的系统独立视图连接到底层系统的地方，利用了作为应用程序开发人员最好远离的各种特定于编译器的东西。

Answer 3

变量名称，因为这是标准库代码，并且应该使用标头中实现细节的保留名称。以下内容不应破坏标准库：

#define mid
#include <algorithm>

因此标准库标头不能使用 mid 作为变量名称，因此不能使用 _Mid。 STL 是不同的 - 它不是语言规范的一部分，它被定义为“这里有一些标头，您可以随意使用它们”

另一方面，如果您的代码或我的代码使用 将是无效的_Mid 作为变量名，因为这是一个保留名称 - 允许实现这样做：

#define _Mid

如果感觉像这样的话。

布局 - 嗯。他们可能有一个风格指南，他们可能或多或少地遵循它。事实上，它与我的风格指南不符（因此会使我的代码审查失败）对他们来说没什么。

难以算出的算子——对谁来说很难？代码应该是为维护它的人编写的，GNU/Dinkumware/任何可能不想让人们在标准库上松懈的人，他们一眼就看不出*--_Next 。如果你使用这种表达方式，你就会习惯它，如果你不这样做，你就会继续觉得很难。

不过，我会告诉你，operator() 重载是胡言乱语。 [编辑：我明白了，它是一个线性同余生成器，非常通用，如果模数为“0”，则意味着仅使用算术类型的自然环绕。]

Answer 4

实施情况各不相同。例如 libc++ 就更容易看懂。但仍然有一些下划线噪音。正如其他人所指出的，不幸的是需要前导下划线。 libc++ 中的相同函数如下：

template <class _Compare, class _BidirectionalIterator>
bool
__next_permutation(_BidirectionalIterator __first, _BidirectionalIterator __last, _Compare __comp)
{
    _BidirectionalIterator __i = __last;
    if (__first == __last || __first == --__i)
        return false;
    while (true)
    {
        _BidirectionalIterator __ip1 = __i;
        if (__comp(*--__i, *__ip1))
        {
            _BidirectionalIterator __j = __last;
            while (!__comp(*__i, *--__j))
                ;
            swap(*__i, *__j);
            _STD::reverse(__ip1, __last);
            return true;
        }
        if (__i == __first)
        {
            _STD::reverse(__first, __last);
            return false;
        }
    }
}

Answer 5

我怀疑部分原因是STL中的代码是高度优化的。正在实现的代码类型的性能比可读性更重要。由于它们的使用如此广泛，因此尽可能快地制造它们是有意义的。

Answer 6

补充一下人们已经说过的，你看到的风格是 GNU 风格。丑陋的？或许，这就是情人眼里出西施。但它是一种严格定义的风格，它确实使所有代码看起来都很相似，而不是难以适应。