STL efficient programming (II)-pay attention to the different characteristics of containers and be careful with codes unrelated to containers

 

STL is built on generics. Array generics are containers and object types are used as parameters. Function generic algorithm, with the iterator type as the parameter. The generic pointer is an iterator that parameterized the type of the object to which it points.

 

This is just the beginning. Independent container types are generalized to sequences or associated containers, and similar containers have similar functions. Standard containers with continuous memory provide random access iterators, and standard node-based containers provide bidirectional iterators. Sequence containers support push_front or push_back, but associated containers do not. The associated container provides lower_bound, upper_bound, and pai_range member functions with log complexity, but the sequential container does not.

 

Understanding the different characteristics of containers is very important for STL programming. Therefore, writing container-independent code is very dangerous. Although STL provides many consistent interface and iterator types.

 

The most enthusiastic "container-independent code" reporter quickly found that writing code that both needs to work with the sequence container and the associated container is meaningless. Many member functions only exist in one type of containers. For example, only sequence containers support push_front or push_back, and only associated containers support count and lower_bound. In different types, even some simple operations such as insert and erase are day-to-day in terms of name and semantics. For example, when you insert an object into a sequence container, it is stored in your position. However, if you insert an object into an associated container, the container will move the object to the location where it should be. For another example, if an iterator is used as a parameter to call erase in a sequence container, a new iterator is returned, but nothing is returned on the associated container.

 

Suppose you want to write a piece of code that can be used on all common sequence containers -- vector, deque, and list. Obviously, you must use the intersection of their interfaces for writing, which means you cannot use reserve or capacity, because deque and list do not support them. Because the existence of list means you have to discard operator [], and you must be limited by the performance of the two-way iterator. This means that you cannot use algorithms that require random access to the iterator, including sort, stable_sort, partial_sort, and nth_element.

 

On the other hand, you are eager to support vector rules, without push_front and pop_front, and using vector and deque will cause Sort failure in splice and member function mode. Under the combination of the above constraints, the latter means that you cannot call any sort on your "Generalized sequence container.

 

This is obvious. If you offend any of the constraints, your code will encounter a compilation error when at least one container you want to use works. It can be seen how sinister this code is.

The culprit here is the different iterator, pointer, and reference failure rules corresponding to different sequence containers. To write code that works properly with vector, deque, and list, you must assume that any iterator that makes those containers, pointers or references to invalid operators really work on the container you are using. Therefore, you must assume that every call to insert invalidates everything, because deque: insert invalidates all iterators, And because capacity, vector :: insert must also be assumed to invalidate all pointers and references. (Clause 1 explains that deque is the only thing that pointers and references are still valid when the iterator fails.) A similar reason can be used to draw a conclusion, all calls to erase must be assumed to invalidate everything.

 

 

For more information, see objective STL.