《C++Primer》第九章-顺序容器-学习笔记(2)-自增长&容器选用

《C++Primer》第九章-顺序容器-学习笔记(2)

文章目录

  • 《C++Primer》第九章-顺序容器-学习笔记(2)
    • vector 容器的自增长
      • capacity 和 reserve 成员
    • 容器的选用
      • 插入操作如何影响容器的选择
      • 元素的访问如何影响容器的选择
      • 选择容器的提示
    • 参考资料
    • 注解

日志:
1,2020-03-12 笔者提交文章的初版V1.0

作者按:
最近在学习C++ primer,初步打算把所学的记录下来。

传送门/推广
《C++Primer》第二章-变量和基本类型-学习笔记(1)
《C++Primer》第三章-标准库类型-学习笔记(1)
《C++Primer》第八章-标准 IO 库-学习笔记(1)
《C++Primer》第十二章-类-学习笔记(1)

vector 容器的自增长

在容器对象中 insert 或压入一个元素时,该对象的大小增加 1。类似地,如果 resize 容器以扩充其容量,则必须在容器中添加额外的元素。标准库处理存储这些新元素的内存分配问题。
一般来说,我们不应该关心标准库类型是如何实现的:我们只需要关心如何使用这些标准库类型就可以了。然而,对于 vector 容器,有一些实现也与其接口相关。为了支持快速的随机访问,vector 容器的元素以连续的方式存放——每一个元素都紧挨着前一个元素存储
已知元素是连续存储的,当我们在容器内添加一个元素时,想想会发生什么事情:如果容器中已经没有空间容纳新的元素,此时,由于元素必须连续存储以便索引访问,所以不能在内存中随便找个地方存储这个新元素。于是,vector 必须重新分配存储空间,用来存放原来的元素以及新添加的元素:存放在旧存储空间中的元素被复制到新存储空间里,接着插入新元素,最后撤销旧的存储空间。
如果 vector 容器在在每次添加新元素时,都要这么分配和撤销内存空间,其性能将会非常慢,简直无法接受。
对于不连续存储元素的容器,不存在这样的内存分配问题。例如,在 list 容器中添加一个元素,标准库只需创建一个新元素,然后将该新元素连接在已存在的链表中,不需要重新分配存储空间,也不必复制任何已存在的元素。由此可以推论:

一般而言,使用 list 容器优于 vector 容器。

但是,通常出现的反而是以下情况:

对于大部分应用,使用 vector 容器是最好的。原因在于,标准库的实现者使用这样内存分配策略:以最小的代价连续存储元素。由此而带来的访问元素的便利弥补了其存储代价

为了使 vector 容器实现快速的内存分配,其实际分配的容量要比当前所需的空间多一些。vector 容器预留了这些额外的存储区,用于存放新添加的元素。
于是,不必为每个新元素重新分配容器。所分配的额外内存容量的确切数目因库的实现不同而不同。比起每添加一个新元素就必须重新分配一次容器,这个分配策略带来显著的效率。事实上,其性能非常好,因此在实际应用中,比起 list 和deque 容器,vector 的增长效率通常会更高。

capacity 和 reserve 成员

vector 容器处理内存分配的细节是其实现的一部分。然而,该实现部分是由 vector 的接口支持的。vector 类提供了两个成员函数:capacityreserve使程序员可与 vector 容器内存分配的实现部分交互工作。capacity操作获取在容器需要分配更多的存储空间之前能够存储的元素总数,而 reserve
操作则告诉 vector 容器应该预留多少个元素的存储空间。
弄清楚容器的capacity(容量)size(长度)的区别非常重要。size 指容器当前拥有的元素个数;而 capacity 则指容器在必须分配新存储空间之前可以存储的元素总数
为了说明 size 和 capacity 的交互作用,考虑下面的程序:

vector<int> ivec;
// size should be zero; capacity is implementation defined
cout << "ivec: size: " << ivec.size()<< " capacity: " << ivec.capacity() << endl;
// give ivec 24 elements
for (vector<int>::size_type ix = 0; ix != 24; ++ix)
	ivec.push_back(ix);
// size should be 24; capacity will be >= 24 and is implementationdefined
cout << "ivec: size: " << ivec.size()<< " capacity: " << ivec.capacity() << endl;

在我们的系统上运行该程序时,得到以下输出结果:

ivec: size: 0 capacity: 0
ivec: size: 24 capacity: 32

由此可见,空 vector 容器的 size 是 0,而标准库显然将其 capacity 也设置为 0。当程序员在 vector 中插入元素时,容器的 size 就是所添加的元素个数,而其 capacity 则必须至少等于 size,但通常比 size 值更大。在上述程序中,一次添加一个元素,共添加了 24 个元素,结果其 capacity 为 32。 容
器的当前状态如下图所示:
在这里插入图片描述
现在,可如下预留额外的存储空间:

ivec.reserve(50); // sets capacity to at least 50; might be more
// size should be 24; capacity will be >= 50 and is implementation defined
cout << "ivec: size: " << ivec.size()
<< " capacity: " << ivec.capacity() << endl;

正如下面的输出结果所示,该操作保改变了容器的 capacity,而其 size 不变:

ivec: size: 24 capacity: 50

下面的程序将预留的容量用完:

// add elements to use up the excess capacity
while (ivec.size() != ivec.capacity())
	ivec.push_back(0);
// size should be 50; capacity should be unchanged
cout << "ivec: size: " << ivec.size() << " capacity: " << ivec.capacity() << endl;

由于在该程序中,只使用了预留的容量,因此 vector 不必做任何的内存分配工作。事实上,只要有剩余的容量,vector 就不必为其元素重新分配存储空间。
其输出结果表明:此时我们已经耗尽了预留的容量,该容器的 size 和capacity 值相等:

ivec: size: 50 capacity: 50

此时,如果要添加新的元素,vector 必须为自己重新分配存储空间:

ivec.push_back(42); // add one more element
// size should be 51; capacity will be >= 51 and is implementationdefined
cout << "ivec: size: " << ivec.size()
<< " capacity: " << ivec.capacity() << endl;

这段程序的输出:

ivec: size: 51 capacity: 100

表明:每当 vector 容器不得不分配新的存储空间时,以加倍当前容量的分配策略实现重新分配。
vector 的每种实现都可自由地选择自己的内存分配策略。然而,它们都必须提供 vector 和 capacity 函数,而且必须是到必要时才分配新的内存空间。分配多少内存取决于其实现方式。不同的库采用不同的策略实现。
此外,每种实现都要求遵循以下原则:确保 push_back 操作高效地在vector 中添加元素。从技术上来说,在原来为空的 vector 容器上 n 次调用push_back 函数,从而创建拥有 n 个元素的 vector 容器,其执行时间永远不能超过 n 的常量倍。

容器的选用

在前面的章节中可见,分配连续存储元素的内存空间会影响内存分配策略和容器对象的开销。通过巧妙的实现技巧,标准库的实现者已经最小化了内存分配的开销。元素是否连续存储还会显著地影响

  • 在容器的中间位置添加或删除元素的代价。
  • 执行容器元素的随机访问的代价。

程序使用这些操作的程序将决定应该选择哪种类型的容器。vector 和 deque容器提供了对元素的快速随机访问,但付出的代价是,在容器的任意位置插入或删除元素,比在容器尾部插入和删除的开销更大。list 类型在任何位置都能快速插入和删除,但付出的代价是元素的随机访问开销较大。

插入操作如何影响容器的选择

list 容器表示不连续的内存区域,允许向前和向后逐个遍历元素。在任何位置都可高效地inserterase 一个元素。插入或删除 list 容器中的一个元素不需要移动任何其他元素。另一方面,list 容器不支持随机访问,访问某个元素要求遍历涉及的其他元素。(list 容器将新元素连接在已存在的链表中)

对于 vector 容器除了vector 容器尾部外,其他任何位置上的插入(或删除)操作都要求移动被插入(或删除)元素右边所有的元素。例如,假设有一个拥有 50个元素的 vector 容器,我们希望删除其中的第 23 号元素,则 23 号元素后面的所有元素都必须向前移动一个位置。否则, vector 容器上将会留下一个空位(hole),而 vector 容器的元素就不再是连续存放的了。

deque 容器拥有更加复杂的数据结构。从 deque 队列的两端插入和删除元素都非常快。在容器中间插入或删除付出的代价将更高。 deque 容器同时提供了list 和 vector 的一些性质:

  • 与 vector 容器一样,在 deque 容器的中间 insert 或 erase 元素效率比较低。
  • 不同于 vector 容器,deque 容器提供高效地在其首部实现 insert 和erase 的操作,就像在容器尾部的一样。
  • 与 vector 容器一样而不同于 list 容器的是, deque 容器支持对所有元素的随机访问
  • 在 deque 容器首部或尾部插入元素不会使任何迭代器失效,而首部或尾部删除元素则只会使指向被删除元素的迭代器失效。在 deque 容器的任何其他位置的插入和删除操作将使指向该容器元素的所有迭代器都失效

元素的访问如何影响容器的选择

vector 和 deque 容器都支持对其元素实现高效的随机访问。也就是说,我们可以高效地先访问 5 号元素,然后访问 15 号元素,接着访问 7 号元素,等等。 由于 vector 容器的每次访问都是距离其起点的固定偏移,因此其随机访问非常有效率。在 list 容器中,上述跳跃访问会变得慢很多。在 list 容器的元素之间移动的唯一方法是顺序跟随指针。从 5 号元素移动到 15 号元素必须遍历它们之间所有的元素。通常来说,除非找到选择使用其他容器的更好理由,否则vector 容器都是最佳选择。

选择容器的提示

下面列举了一些选择容器类型的法则:

  1. 如果程序要求随机访问元素,则应使用vector 或 deque 容器

  2. 如果程序必须在容器的中间位置插入或删除元素,则应采用list 容器

  3. 如果程序不是在容器的中间位置,而是在容器首部或尾部插入或删除元素,则应采用 deque 容器

  4. 如果只需在读取输入时在容器的中间位置插入元素,然后需要随机访问元素,则可考虑在输入时将元素读入到一个 list 容器,接着对此容器重新排序,使其适合顺序访问,然后将排序后的 list 容器复制到一个 vector容器。

  5. 如果程序既需要随机访问又必须在容器的中间位置插入或删除元素,那应该怎么办呢?
    此时,选择何种容器取决于下面两种操作付出的相对代价:随机访问 list 容器元素的代价,以及在 vector 或 deque 容器中插入/删除元素时复制元素的代价。通常来说,应用中占优势的操作(程序中更多使用的是访问操作还是插入/删除操作)将决定应该什么类型的容器

决定使用哪种容器可能要求剖析各种容器类型完成应用所要求的各类操作的 性能。

如果无法确定某种应用应该采用哪种容器,则编写代码时尝试 只使用 vector 和 lists 容器都提供的操作:使用迭代器,而不是下标,并且避免随机访问元素。这样编写,在必要时,可很方便地将程序从使用 vector 容器修改为使用 list 的容 器。

参考资料

【1】C++ Primer 中文版(第四版·特别版)

注解

你可能感兴趣的:(C++)