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

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算法和队列头。

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

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

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

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

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

（请注意，这些规则禁止类似__MY_FILE_H我经常见到的标题保护。）

尼尔·巴特沃思（Neil Butterworth）现在被列为“匿名”，在他对SO问题“ STL的可读实现吗？”的回答中提供了有用的链接。。在那里引用他的答案：

由原始STL设计师Stepanov＆Lee（与PJ Plauger和David Musser共同）合着的《 C ++标准模板库》一书描述了可能的实现，并附有代码-请参见 http://www.amazon。 co.uk/C-Standard-Template-Library/dp/0134376331。

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

无论如何，大多数STL代码（在STL中，我的意思是C ++标准库的类似STL的子集）都是模板代码，因此必须是仅标头的，并且由于几乎所有程序都使用了它，因此值得付出代码越短越好。

因此，简洁性和可读性之间的自然取舍点在量表的简洁性端比“普通”代码要远得多。

另外，在标准库中，应用程序代码的与系统无关的视图与底层系统连接在一起，并利用您作为应用程序开发人员应尽量避免的各种特定于编译器的事物。

变量名是因为它是标准库代码，因此应使用保留名称作为标头中的实现详细信息。以下应不打破标准库：

#define mid
#include <algorithm>

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

另一方面，如果将您的代码或我的代码用作_Mid变量名，则该代码或我的代码将是无效的，因为这是保留名称-允许执行该操作：

#define _Mid

如果感觉像这样。

布局-嗯。他们可能有一个样式指南，他们或多或少会遵循它。它们与我的样式指南不匹配（因此将使我的代码审查失败）这一事实对他们而言并不重要。

难以解决的操作员-对谁难？应该为维护它的人员编写代码，而GNU / Dinkumware //可能不想让人们松开*--_Next一眼就无法理解的标准库的代码。如果您使用这种表达方式，就会习惯它，否则，您会继续感到困难。

不过，我会给您的是，这种operator()超载是乱码。[编辑：我明白了，它是线性同余生成器，非常通用，如果模数为“ 0”，则意味着仅使用算术类型的自然环绕。

实现方式各不相同。 例如，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;
        }
    }
}

我怀疑部分原因是STL中的代码已高度优化。正在实现的代码种类的性能比可读性要重要得多。因为它们被广泛使用，所以使它们尽可能快是有意义的。

加上人们已经说过的话，您看到的样式就是GNU样式。丑陋？也许，这是情人眼中的。但这是严格定义的样式，它确实使所有代码看起来都相似，而不是难以适应。