标签：effective stl c++
C++提供了几种不同的容器供我们选择，这里简单回顾一下：
1、标准STL序列容器：vector、string、deque和list。
2、标准STL关联容器：set、multiset、map、和multimap。
3、非标准序列容器slist和rope。slist是一个单向链表，rope本质上是一“重型”string。
4、非标准关联容器hash_set、hash_multiset、hash_map和hash_multimap。
5、vector<char>作为string的替代。
6、vector作为标准关联容器的替代。
7、几种标准的非STL容器，包括数组、bitset、valarry、stack、queue和priority_queue.
稍后我们将讨论与算法复杂性相对应得有关容器的重要问题。这里首先引入对STL容器的一种分类方法，也就是对连续内存容器（contiguous-memorycontainer）和基于节点的容器（node-based container）的区分。
连续内存容器（或称为基于数组的容器，array-based container）把它的元素存放在一块或多块（动态分配的）内存中，每块内存中存有多个元素。当有新元素插入或已有的元素被删除时，同一内存块中的其他元素要向前或向后移动，以便为新元素让出空间，或者填充被删除元素所留下的空隙。这种移动影响到效率和异常安全性。标准的连续内存容器有vector、string和deque。非标准的rope也是一个连续内存容器。
基于节点的容器在每一个（动态分配的）内存中只存放一个元素。容器中元素的插入或删除只影响到指向节点的指针，而不影响节点本身的内容，所以当有插入或删除操作时，元素的值不需要移动。表示链表的容器，如list和slist，是基于节点的。所有标准的关联容器也是如此（通常的实现方式为平衡树）。非标准的散列容器使用不同的基于节点的实现。
有了上面的术语作为基础，下面将概括出选择容器时最重要的一些问题。
l 你是否需要在容器的任意位置插入新元素？如果需要，就选择序列容器；关联容器是不行的。
l 你是否关心容器中的元素是排序的？如果不关心，则散列容器是一个可行的选择方案；否则，你要避免散列容器。
l 你选择的容器必须是标准C++的一部分吗？如果必须是，就排除了散列的容器，slist和rope。
l 你需要哪种类型的迭代器？如果它们必须是随机访问迭代器，则对容器的选择就被限定为vector、deque和string。或许你也可以考虑一下rope。如果要求使用双向迭代器，那么你要避免slist。
l 当发生元素的插入或删除操作时，避免移动容器中原来的元素是否很重要？如果是，就要避免连续内存容器。
l 容器中数据的布局是否需要和C兼容？如果需要兼容，就要只能选择vector。
l 元素的查找速度是否是关键的考虑因素？如果是，就要散列容器、排序的vector和标准关联容器——或许这就是优先顺序。
l 如果容器内部使用了引用计数技术（reference counting），你是否介意？如果是，就要避免使用string，因为许多string的实现都使用了引用计数。Rope也要避免，因为权威的rope实现是基于引用计数的。当然，你需要某种表示字符串的方法，这时你可以考虑vector<char>。
l 对插入和删除操作，你需要事务语义（transaction semantics）吗？也就是说，在插入和删除操作失败时，你需要回滚的能力吗？如果需要，你就要使用基于节点的容器。如果对多个元素的插入操作（即针对一个区间的形式）需要事务，则你需要选择list，因为在标准容器中，只有list对多个元素的插入操作提供了事务语义。对那些希望编写异常安全（exception-safe）代码的程序员，事务语义显得尤为重要。（使用连续内存的容器也可以获得事务语义，但是要付出性能上的代价，而且代码也显得不那么直截了当。
l 你需要使迭代器、指针和引用变为无效的次数最少吗？如果是这样，就要使用基于节点的容器，因为对这类容器的插入和删除操作从来不会使迭代器、指针和引用变为无效（除非他们指向了一个你正在删除的元素）。而针对连续内存容器的插入和删除操作一般会使指向该容器的迭代器、指针、和引用变为无效。
l 如果序列容器的迭代器是随机访问类型，而且只要没有删除操作发生，且插入操作只发生在容器的末尾，则指向数据的指针和引用就不会变为无效这样的容器是否对你有帮助吗？这是非常特殊的情形，但如果你面对的情形正是如此，则deque是你所希望的容器。（有意思的是，当插入操作仅在容器的末尾发生时，deque的迭代器有可能会变为无效。deque是唯一的、迭代器可能会变为无效，而指针和引用不会变为无效的STL标准容器。）
标签：effective stl c++
原文地址：http://blog.csdn.net/u012432778/article/details/42062679
