- Standard STL sequence container: Vector, String, deque, and list.
- Standard STL associated container: Set, Multiset, map, and multimap.
- Non-standard sequence containerSlist and rope. Slist is a one-way linked list, and rope is essentially a heavy string. ("Rope" is a heavy "string ". Do you understand ?) You can find an overview of these non-standard (but common) containers in Clause 50.
- Non-standard associated containerHash_set, hash_multiset, hash_map, and hash_multimap. In Clause 25, I checked the differences between these widely available hash table-based containers and standard associated containers.
- Vector <char> can be used as a replacement for string.Clause 13 describes the potential significance of this alternative.
- Vector is a substitute for standard associated containers.As mentioned in cla23, sometimes vector can be better than standard associated containers in terms of time and space.
- Several TypesStandard non-STL container, Including array, bitset, valarray, stack, queue, and priority_queue. Because they are non-STL containers, I seldom talk about them in this book, although clause 16 mentions a situation where arrays are more advantageous than STL containers, clause 18 reveals why bitset may be better than vector <bool>. It is worth noting that arrays can work with STL algorithms because pointers can be used as arrays as iterators.
This is all options, and the range of options that can be considered is as rich as the options between them. Unfortunately, most of STL's discussions are limited to a narrow field of view in the container world, ignoring many questions about choosing the right container. Even the standards are involved in this action and provide the following guidelines for selection between vector, deque, and list:
Vector, list, And deque provide programmers with different complexities. Therefore, vector is a sequence type that can be used by default, when you insert or delete the middle part of a sequence frequently, you should use list. You can select deque as the data structure when most of the inserts and deletions occur at the header or end of the sequence.
If you are concerned about algorithm complexity, I think this solution is a reasonable suggestion, but you need to care more about it.
Now, we need to check some important container-related issues that can supplement algorithm complexity, but first I need to introduce an STL container classification method, it is not discussed as frequently as it should. That is the difference between a continuous memory container and a node-based container.
Continuous memory container(Also calledArray-based container) Save their elements in one or more (dynamically allocated) memory blocks. If a new element is found or the existing element is deleted, other elements in the same memory block must move up or down to provide space for the new element or fill the space occupied by the original deleted element. This movement affects efficiency (see Terms 5 and 14) and exceptional security (as we will see ). The standard continuous memory containers are vector, string, and deque. Non-standard rope is also a continuous memory container.
Node-based containerOnly one element is saved in each memory block (dynamically allocated. The insertion or deletion of container elements only affects the pointer to the node, not the content of the node. So when something is inserted or deleted, the element value does not need to be moved. Containers represented as linked lists, such as list and slist, are node-based and all standard associated containers are also (their typical implementation is the Balance Tree ). Non-standard hash containers use different node-based implementations, as we will see in Clause 25.
Using this inappropriate term, we are prepared to describe most of the issues about inter-container selection. In this discussion, I skipped the consideration of non-STL class containers (such as arrays and bitsets), because this is a book about STL after all.
- Do you need the ability to "Insert a new element anywhere in the container?If yes, you need a serial container, and the associated container cannot.
- Do you care about the order of elements in the container?If not, the hash container is a viable option. Otherwise, avoid using the hash container.
- Must containers in Standard C ++ be used?If yes, you can remove the hash container, slist, and rope.
- What type of iterator do you need?? If it must be a random access iterator, technically you can only be limited to vector, deque, and string, but you may also consider rope (more information about rope is in Clause 50 ). If a two-way iterator is required, you will not be able to use slist (see clause 50) or the general implementation of the hash container (see clause 25 ).
- When inserting or deleting data, do you really care about moving existing elements in the container?If yes, you must discard the continuous memory container (see clause 5 ).
- Is the memory layout of the data in the container compatible with C?If yes, you can only use vector (see section 16 ).
- Is search speed important?If yes, you should look at the hash container (see clause 25), the sorted vector (see clause 23) and the standard associated container-probably in this order.
- Do you mind if reference count is used at the bottom layer of the container?If yes, you have to avoid string, because many string implementations use reference count (see clause 13 ). You cannot use rope either, because the authoritative rope implementation is based on reference count (see article 50 ). So you have to review your string. You can consider using vector <char>.
- Do you need to insert and delete the transactional (transactional) semantics?That is to say, do you need the ability to roll back insert and delete reliably? If yes, you need to use a node-based container. If you need to insert multiple elements (for example, in a range-See Clause 5) for transactional semantics, you should select list, because list is the only standard container that provides multi-element insertion of transactional semantics. Transactional semantics is very important for programmers interested in writing exceptional security code. (Transactional semantics can also be implemented on the continuous memory container, but it has a performance overhead and the code is not so intuitive. For more information, see Clause 17 [8] of suttter's exceptional C ++.)
- Do you want to minimize the number of failures of the iterator, pointer, and reference?If yes, you should use a node-based container, because inserting and deleting these containers will not invalidate the iterator, pointer, and reference (unless they point to the elements you have deleted ). Generally, inserting or deleting a continuous memory container will invalidate all iterators, pointers, and references pointing to the container.
- Do you need sequence containers with the following features: 1) random access iterators can be used; 2) as long as they are not deleted and insertion only occurs at the end of the container, will pointer and referenced data not expire?This is a very special situation, but if you encounter this situation, deque is your dream container. (Interestingly, the deque iterator may also become invalid when the insert is only at the end of the container, deque is the only standard STL container that "will not invalidate its pointer and reference when the iterator fails .)
These problems are hardly the end of the process. For example, they do not focus on using different memory configuration policies for different container types (terms 10 and 14 discuss some aspects of these policies ). However, they are enough to convince you, unless you have compatibility with element sequence, standard consistency, iterator capability, memory layout and C, search speed, irregular behavior caused by reference count, easy implementation of transactional semantics, and iterator no interest in invalid conditions, you have to spend more time on the algorithm complexity of container operations. Of course, this complexity is important, but it is far from the whole story.
When facing the container, STL gives you many options. If your line of sight is beyond the STL range, there will be more options. Make sure that all your options are taken into account before selecting a container. A "Default container "? I don't think so.
