一、回顾C++提供的容器
Ø 标准的STL序列容器
vector、string、deque和list。
Ø 标准的STL关联容器
set、multiset、map和multimap。
Ø 非标准序列容器
slist和rope。
Ø 非标准的关联容器
hash_set、hash_multiset、hash_map和hash_multimap。
Ø 几种标准的非STL容器
数组、bitset、valarray、stack、queue和priority_queue。
二、一些常见的容器选择问题
Ø 你是否需要在容器的任意位置插入新元素?
如果需要,就选择序列容器;关联容器是不行的。
Ø 你是否关心容器中的元素是如何排序的?
如果不关心,则哈希容器是一个可行的选择方案;否则,你要避免哈希容器。
Ø 你选择的容器必须是标准C++的一部分吗?
如果必须是,就排除了哈希容器、slist和rope。
Ø 你需要哪种类型的迭代器?
如果它们必须是随机访问迭代器,则对容器的选择就被限定为vector、deque和string。或许你也可以考虑rope。如果要求使用双向迭代器,那么你必须避免slist以及哈希容器的一个常见实现。
Ø 当发生元素的插入或删除操作时,避免移动容器中原来的元素是否很重要?
如果是,就要避免连续内存的容器。
Ø 容器中的数据的布局是否需要和C兼容?
如果需要兼容,就只能选择vector容器。
Ø 元素的查找速度是否关键的考虑因素?
如果是,就要考虑哈希容器,排序的vector,和标准关联容器 --- 或许这就是优先顺序。
Ø 如果容器内部使用了引用计数技术(reference counting),你是否介意?
如果是,就要避免使用string,因为许多string的实现都是用了引用计数。Rope也需要避免,因为权威的rope实现是基于引用计数的。当然,你需要某种表示字符串的方法,可以考虑vector<char>。
Ø 对插入和删除操作,你需要事务语义(transactional semantics)吗?也就是说在插入和删除操作失败时,你需要回滚的能力吗?
如果需要,你就要使用基于节点的容器。如果对多个元素的插入操作需要事务语义,则你需要选择list,因为在标准容器中,只有list对多个元素的插入操作提供了事务语义。
Ø 你需要使迭代器、指针和引用变为无效的次数最少吗?
如果是这样,就要使用基于节点的容器,因为对这类容器的插入和删除操作从来不会使迭代器、指针和引用变为无效(除非它们指向了一个你正在删除的元素)。而针对连续内存容器的插入和删除操作一般会使指向该容器的迭代器、指针和引用变为无效。
Ø 如果序列容器的迭代器是随机访问迭代器类型,而且只要没有删除操作发生,且插入操作只发生在容器的末尾,则指向数据的指针和引用就不会变为无效,这样的容器是否对你有帮助?
这是非常特殊的情况,但如果你面对的情形正是如此,则deque是你所希望的容器。(有意思的是,当插入操作仅在容器末尾发生时,deque的迭代器有可能变为无效。deque是唯一的迭代器可能会变为无效而指针和引用不会变为无效的STL标准容器。)
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/alais/archive/2006/09/05/1180942.aspx
标准STL序列容器:vector,string,deque,list。
标准STL关联容器:set,multiset,map,multimap。
非标准序列的关联容器:slist,rope。slist是单向列表,rope是“重量级字符串类”。string不是“线”嘛,rope就是“绳子”......汗
非标准的关联容器hash_set,hash_multiset,hash_map,hash_multimap(哈希容器可不是标准C++的一部分啊,当然,如上,slist,rope也不是)。
vector<char>可以作为string的替代。
如果关心容器中的元素是如何排序的,可选择哈希容器(比如什么hash_set,hashmap之类的);否则避免。
容器中数据的布局如果要和C兼容,就只能选择vector。
如果元素查找速度很重要,就考虑哈希容器,排序的vector,标准关联容器。
string,rope内部使用了引用计数技术reference counting。
在插入和删除失败时,如果需要回滚(称事务语义),就考虑使用基于节点的容器(比如list,slist);如果对多个元素的插入需要事务语义,则选择list,而且只选择list。
如果需要使迭代器,指针,引用变为无效的次数最少,就选择基于节点的容器。针对连续内存容器的插入和删除一般会使指向该容器的迭代器,指针,引用变为无效。
deque是唯一的一种STL标准容器,其迭代器可能会变为无效,而指针和引用不会失效。