list::size() 真的是 O(n) 吗？

Question

最近，我注意到有人提到std::list::size()具有线性复杂度。
根据一些消息来源，这实际上取决于实现，因为标准没有说明复杂性必须是什么。
此博客条目中的评论说：

实际上，这取决于您使用的是哪个 STL。 Microsoft Visual Studio V6 将 size() 实现为 {return (_Size); } 而 gcc （至少在 3.3.2 和 4.1.0 版本中）这样做为 { return std::distance(begin(), end()); 第一个具有恒定速度，第二个具有 o(N) 速度

1. 所以我的猜测是，对于 VC++ 人群size()具有恒定的复杂性，因为 Dinkumware 自 VC6 以来可能不会改变这一事实。 我在那儿吗？
   
2. 目前在gcc中是什么样的？ 如果真的是O(n)，为什么开发者会选择这样做呢？

Answer 1

在 C++11 中，要求对于任何标准容器， .size()操作必须以“恒定”复杂度 (O(1)) 完成。 （表 96 — 集装箱要求）。 以前在 C++03 中.size()应该具有恒定的复杂性，但不是必需的（参见Is std::string size() a O(1) operation? ）。

n2923引入了标准的变化：指定 size() 的复杂性（修订版 1） 。

但是，libstdc++ 中.size() ) 的实现在 gcc 高达 4.8 中仍然使用 O(N) 算法：

  /**  Returns the number of elements in the %list.  */
  size_type
  size() const _GLIBCXX_NOEXCEPT
  { return std::distance(begin(), end()); }

另请参阅为什么 c++11 上的 std::list 更大？ 详细了解为什么保持这种方式。

更新：在 C++11 模式（或更高版本）下使用 gcc 5.0时， std::list::size()正确为 O(1 )。

---

顺便说一下，libc++ 中的.size()是正确的 O(1)：

_LIBCPP_INLINE_VISIBILITY
size_type size() const _NOEXCEPT     {return base::__sz();}

...

__compressed_pair<size_type, __node_allocator> __size_alloc_;

_LIBCPP_INLINE_VISIBILITY
const size_type& __sz() const _NOEXCEPT
    {return __size_alloc_.first();}

Answer 2

Pre-C++11 答案

您是正确的，标准没有说明list::size()的复杂性必须是什么 - 但是，它确实建议它“应该具有恒定的复杂性”（表 65 中的注释 A）。

这是 Howard Hinnant 的一篇有趣的文章，它解释了为什么有些人认为list::size()应该具有 O(N) 复杂度（主要是因为他们认为 O(1) list::size()使list::splice()具有O(N) 复杂度）以及为什么 O(1) list::size()是一个好主意（在作者看来）：

• http://howardhinnant.github.io/On_list_size.html

我认为论文的主要观点是：

• 很少有维护内部计数的情况，因此list::size()可以是 O(1) 导致拼接操作变为线性
• 可能还有更多的情况，有人可能不知道可能发生的负面影响，因为他们调用了 O(N) size() （例如他的一个示例，其中list::size()在持有锁时被调用）。
• 而不是允许size()是 O(N)，为了“最少惊喜”，标准应该要求任何实现size()容器以 O(1) 方式实现它。 如果一个容器不能做到这一点，它根本不应该实现size() 。 在这种情况下，容器的用户将知道size()不可用，如果他们仍然想要或需要获取容器中元素的数量，他们仍然可以使用container::distance( begin(), end())以获得该值 - 但他们将完全意识到这是一个 O(N) 操作。

我想我倾向于同意他的大部分推理。 但是，我不喜欢他对splice()重载的提议。 其在通过n必须等于distance( first, last) ，以获得正确的行为似乎是很难诊断错误的配方。

我不确定应该或可以做什么，因为任何更改都会对现有代码产生重大影响。 但就目前而言，我认为现有代码已经受到影响 - 对于本应明确定义的某些内容，从一种实现到另一种实现的行为可能会有相当大的不同。 也许某人关于将大小“缓存”并标记为已知/未知的评论可能会很好地工作 - 您会得到分摊 O(1) 行为 - 唯一一次获得 O(N) 行为是当列表被某些 splice() 操作修改时. 这样做的好处是，它可以由今天的实现者完成，而无需更改标准（除非我遗漏了一些东西）。

据我所知，C++0x 在这方面没有改变任何东西。

Answer 3

我之前不得不查看 gcc 3.4 的list::size ，所以我可以这样说：

1. 它使用std::distance(head, tail) 。
2. std::distance有两种实现：对于满足RandomAccessIterator 的类型，它使用“tail-head”，对于仅满足InputIterator 的类型，它使用依赖于“iterator++”的 O(n) 算法，计数直到遇到给定的尾巴。
3. std::list不满足RandomAccessIterator ，因此大小为 O(n)。

至于“为什么”，我只能说std::list适用于需要顺序访问的问题。 将大小存储为类变量会在每次插入、删除等时引入开销，并且根据 STL 的意图，这种浪费是一个很大的禁忌。 如果您确实需要恒定时间size() ，请使用std::deque 。

Answer 4

我个人不认为拼接 O(N) 的问题是允许大小为 O(N) 的唯一原因。 你不为你不使用的东西付费是一个重要的 C++ 座右铭。 在这种情况下，无论您是否检查列表的大小，保持列表大小都需要在每次插入/擦除时进行额外的增量/减量。 这是一个很小的固定开销，但仍然需要考虑。

很少需要检查列表的大小。 从头到尾迭代而不关心总大小是非常常见的。

Answer 5

我会去源（ 存档）。 SGI 的 STL 页面说它允许具有线性复杂性。 我相信他们遵循的设计准则是允许列表实现尽可能通用，从而在使用列表时提供更大的灵活性。

Answer 6

这个错误报告： [C++0x] std::list::size complex ，捕捉到了一个事实，即 GCC 4.x 中的实现是线性时间以及 C++11 向恒定时间的转换是如何缓慢的由于 ABI 兼容性问题，即将推出（在 5.0 中可用）。

GCC 4.9 系列的联机帮助页仍然包含以下免责声明：

对 C++11 的支持仍处于试验阶段，可能会在未来版本中以不兼容的方式进行更改。

---

此处引用了相同的错误报告：应在 C++11 中 std::list::size 具有恒定的复杂性吗？

Answer 7

如果您正确使用列表，您可能不会注意到任何区别。

列表适用于您想在不复制的情况下重新排列的大数据结构，对于您想在插入后保留有效指针的数据。

在第一种情况下它没有区别，在第二种情况下我更喜欢旧的（较小的） size() 实现。

无论如何，标准比原始速度更多地是关于正确性和标准行为以及“用户友好性”。

Answer 8

这可以清楚地显示在当前的 GCC 源代码中：size() 的实现如下

  _GLIBCXX_NODISCARD
  size_type
  size() const _GLIBCXX_NOEXCEPT
  { return _M_node_count(); }

它调用了_M_node_count()，_M_node_count的实现如下：

    #if _GLIBCXX_USE_CXX11_ABI
      static size_t
      _S_distance(const_iterator __first, const_iterator __last)
      { return std::distance(__first, __last); }

      // return the stored size
      size_t
      _M_node_count() const
      { return this->_M_get_size(); }
#else
      // dummy implementations used when the size is not stored
      static size_t
      _S_distance(const_iterator, const_iterator)
      { return 0; }

      // count the number of nodes
      size_t
      _M_node_count() const
      { return std::distance(begin(), end()); }
#endif

如果 _GLIBCXX_USE_CXX11_ABI 设置为 0，则 size() 为 O(N)，否则为 O(1)。 _GLIBCXX_USE_CXX11_ABI set to 0 will happen when you use a high version GCC compiled libraries and need link to a low version GCC compiled libraries, for example, your system have installed a GCC 4.8 compiled GTEST libraries, but your code now use GCC 7.3 and use C++11 ，并且您需要链接到该库，在这种情况下，您需要将以下内容添加到您的 CMakeLists.txt 中，否则会出现链接问题。

add_compile_definitions(_GLIBCXX_USE_CXX11_ABI=0)