stl containers usage empirical—— from Effective STL

Do you need to be able to insert a new element at an arbitrary position in the
container? If so, you need a sequence container: associative containers won't
do.
• Do you care how elements are ordered in the container? If not. a hashed
container becomes a viable choice. Otherwise, you'll want to avoid hashed
containers.
• Must the container be part of standard C++? If so, that eliminates hashed
containers, slist, and rope.
• What category of iterators do you require? If they must be random access
iterators, you're technically limited to vector, deque, and string, but you'd
probably want to consider rope, too. (See Item 50 for information on rope.) If
bidirectional iterators are required, you must avoid slist (see Item 50) as well as
one common implementation of the hashed containers (see Item 25).
• Is it important to avoid movement of existing container elements when
insertions or erasures take place? If so, you'll need to stay away from
contiguous-memory containers (see Item 5).
• Does the data in the container need to be layout-compatible with C? If so,
you're limited to vectors (see Item 16).
• Is lookup speed a critical consideration? If so, you'll want to look at hashed
containers (see Item 25), sorted vectors (see Item 23), and the standard
associative containers — probably in that order.
• Do you mind if the underlying container uses reference counting? If so, you'll
want to steer clear of string, because many string implementations are
reference-counted (see Item 13). You'll need to avoid rope, too, because the
definitive rope implementation is based on reference counting (see Item 50).
You have to represent your strings somehow, of course, so you'll want to
consider vector<char>.
• Do you need transactional semantics for insertions and erasures? That is, do
you require the ability to reliably roll back insertions and erasures? If so, you'll
want to use a node-based container. If you need transactional semantics for
multiple-element insertions (e.g., the range form — see Item 5), you'll want to
choose list, because list is the only standard container that offers transactional
3
semantics for multiple-element insertions. Transactional semantics are
particularly important for programmers interested in writing exception-safe
code. (Transactional semantics can be achieved with contiguous-memory
containers, too, but there is a performance cost, and the code is not as
straightforward. To learn more about this, consult Item 17 of Sutter's
Exceptional C++ [8].)
• Do you need to minimize iterator, pointer, and reference invalidation? If so,
you'll want to use node-based containers, because insertions and erasures on
such containers never invalidate iterators, pointers, or references (unless they
point to an element you are erasing). In general, insertions or erasures on
contiguous-memory containers may invalidate all iterators, pointers, and references
into the container.
• Would it be helpful to have a sequence container with random access iterators
where pointers and references to the data are not invalidated as long as nothing
is erased and insertions take place only at the ends of the container? This is a
very special case, but if it's your case, deque is the container of your dreams.
(Interestingly, deque's iterators may be invalidated when insertions are made
only at the ends of the container, deque is the only standard STL container
whose iterators may be invalidated without also invalidating its pointers and
references.)