Item18 Avoid using Vector as a STL container, Vector has two questions. First, it is not a real STL container, second, it does not save the BOOL type. In addition, there is not too much thing to be related to this topic (translation, not enough?)
One thing can't be a STL container, just because someone will say it is a (translation,: (). One thing is to be a STL container, you must meet all container requirements listed on the C Standard 23.1. In these requirements, there is this One: If c is a T type element container, and c supports Operator [] The following code must be able to compile:
T * p = & c [0]; // Initialize a T * with the address // of whatver operator [] returns
In other words, if you use Operator [] to get one T object in Container , you can take the address to get a pointer. (Suppose T does not overload Opertor &. Translation: The original sentence for this assumes That T Hasn't Perveryly Overloaded Operators. So, if vector may become a container, these code must be compiled:
Vector v; bool * pb = & v [0]; // Initialize a Bool * with the address of // what vector :: operator [] returns
But it can't compile. The reason is that vector is a pseudo-container, which does not save real BOOL, but package BOOL to save space. In a typical implementation, each "BOOL "Save in" Vector "is a" bit ", one byte of 8-bit will save 8 bool. From the inside, Vector uses the same idea as the bitfields to indicate Save the BOOL value.
Similar to the BOOL value, the bit field is only two values, but there is an important difference between them: You can create a pointer to the true BOOL type, but point to a separate pointer is illegal.
Considering the illegal point to the individual one-bit pointer, this is a problem for the design of Vector . Because the return value of Vector :: Operator [] is T & Type. If Vector Save the true BOOL value This is not a problem. But because it doesn't, Vector :: operator [] (translation: the original () doubt) I don't know how to return a reference, there is no such thing.
In order to solve it, Vector :: operator [] returns an object, its behavior is similar to bit reference, also known as a proxy object. (Use only STL, you don't need to understand what is a proxy. It is a dedicated Understand C technology. For the agent's information, refer to more Effective C Item 30 also has a Gamma et al. (The GOF) design pattern book, Proxy chapter). In-in-inquiry, vector may be similar to this:
template vector {public: class reference {...}; // class to generate proxies for // references to individual bits reference operator [] (size_type n); // operator [] returns a proxy ...}
Now, these code cannot be compiled. Vector v; bool * pb = & v [0]; // error! The expression on Tne Right is // of type vector :: Reference * , // not bool *
Because it can't be compiled, it is not satisfied with the need for STL containers. Vector is in the standard, it also meets the needs of most STL containers, but it is not good enough. You write the code of the STL container The more, the more you will recognize this. When you come, I promise, when you write a template, it works only when you get the address of the container element. In that time, you will suddenly understand The container and the difference between the container are almost a container.
Maybe you want to know why vector exists in the standard, and it is not a container. The answer is related to the experiment of a noble failed. But let's postpone discussing, I have a more pressing problem. If vector Should be avoided, because it is not a container, then what should I use when needing a vector ?
There are two replacements that meet almost all needs. The first is deque .deque offers almost all vectors (the only thing worth noting is RESERVE and CAPACITY), and Deque is a STL Containers, it saves real BOOL values. Of course, the memory of the Deque cannot be delivered to a c api of the BOOL array (see item 16), but vector cannot be passed to a BOOL array. This is not used to get data in Vector without the portable method. (The technology in Item 16 cannot be compiled on Vector . Because this technology depends on pointers that can get container elements. I mentioned Don't save the BOOL value in vector ?)
The second Vector is bitset.bitset is not a STL container, but it is part of the C standard library. Unlike the STL container, its size (total element) is fixed. So, it does not support Insert and delete elements, near step, because it is not a STL container, it does not support iterator. Similar to Vector , it uses a compressed representation, making each value only one bit. It provides Vector Special member functions also contain special member functions for Collection of Bits. If there is no iterator and dynamic size, then BitSet may be in touch with you.
Now let's discuss the experiment of the failure of the aristocrat, it is in the standard library of Vector . I have mentioned the code object in the C programming. C standard committee member of course Also realized that they decided to develop Vector as a demonstration. It shows how STL supports containers that contain through the proxy access element. One but this example appears in the standard, and it shows very detailed, developers will have one Refer to your own agent-based container.
However, they finally discovered that it is impossible to create a proxy-based container that meets the needs of all STL containers. For some reason, they failed, and this example in the development is in the standard. Maybe someone will explore the vector The reason for existence, but in real, this does not affect what. It is: Vector does not meet the needs of STL containers; you'd better not use it; Deque and bitset are basic to meet you Need vector substitute.
