Valid STL Clause 18

Item18 avoid using vector <bool>
 
As an STL container, vector <bool> has two problems. First, it is not a real STL container, and second, it does not save the bool type.
In addition, there are not many things related to this topic)

One thing cannot be an STL container, because someone will say it is a (, :(). To become an STL container, one thing must satisfy all
Container requirements listed in section 23.1 of the C ++ standard. Among these requirements, there is one: if C is a T-type element container, and C supports operator []
The following code must be compiled:

T * P = & C [0]; // initialize a T * with the address
// Of whatever operator [] returns

In other words, if you use operator [] to get a t object in the iner <t>, you can get an address for it to get a pointer.
(Suppose t does not load opeartor &. Note: The original sentence is this assumes that t hasn't perversely overloaded operators.
Therefore, if Vector <bool> may become a container, the Code must be compiled through:

Vector <bool> V;
Bool * pb = & V [0]; // initialize a bool * with the address
// What vector <bool>: operator [] returns

However, it cannot be compiled. The reason is that vector <bool> is a pseudo-container. It does not save the real bool,
Package bool to save space. In a typical implementation, every "bool" stored in "vector" is a byte of "bit" and 8-bit.
Eight bool values will be saved. Internally, vector <bool> uses the same idea as bitfields to represent the bool values to be saved.

Similar to bool values, bit fields only have two values, but there is an important difference between them: You can create a pointer pointing to the real bool type, but it refers
The pointer to a single unique digit is invalid.

Considering that the pointer pointing to a single uniqueness is invalid, this poses a problem for the design of vector <bool>, because the return value of vector <t>: operator []
Is T & type. If vector <bool> saves the real bool value, this is not a problem. But because it does not exist, vector <bool >:: operator []
I do not know how to return a reference. There is no such thing.

To solve this problem, vector <boo>: operator [] returns an object, which acts like a bitwise reference, also called a proxy object. (only STL is used,
You don't need to understand what proxy is. It is a C ++ technology worth understanding. For more information about proxy, see item30 of more effective tive C ++.
There is also the proxy chapter in the design pattern book of Gamma et al. (gof). In essence, vector <bool> may look like this:

Template <typename Allocator>
Vector <bool, Allocator> {
Public:
Class reference {...}; // class to generate proxies
// References to individual bits
Reference operator [] (size_type N); // operator [] returns a proxy
...
}

The reason for these codes being unable to be compiled is obvious.

Vector <bool> V;
Bool * pb = & V [0]; // error! The expression on tne right is
// Of Type Vector <bool>: reference *,
// Not bool *

Because it cannot be compiled, vector <boo> does not meet the needs of STL containers. Vector <bool> meets the needs of most STL containers in the standard.
But it is not good enough. The more code you write on the STL container, the more deeply you will understand this point. When one day comes, I promise that when you write
A template works only when the address of the container element can be obtained. At that time, you will suddenly understand the difference between a container and almost a container.

Maybe you want to know why vector <bool> exists in the standard, and it is not a container. The answer is related to an aristocratic failure experiment. But let us
I have a more urgent question to postpone the discussion. If vector <bool> should be avoided because it is not a container, when a vector <bool> is needed
What should I use?

The standard library provides two replicas that meet almost all requirements. The first one is that deque <bool>. deque provides almost all vectors (the only one is worth
Note: Reserve and capacity), and deque <bool> is an STL container that stores the real bool value. Of course, the underlying memory of deque is not continuous.
Therefore, the data in deque <bool> cannot be passed to a c api that expects to get the bool array (see item 16), but the vector <bool> cannot do this either.
Because no portable method is used to obtain data in vector <bool> (the technology in item16 cannot be compiled on vector <boo>, because this technology relies on
The pointer to the container element can be obtained. I mentioned that bool values are not saved in vector <bool>, right ?)

The second substitution of vector <bool> is bitset. bitset is not an STL container, but it is part of the C ++ standard library. Its size is different from that of the STL container.
(Total number of elements) is fixed during the compilation period. Therefore, it does not support inserting or deleting elements. The last step is because it is not an STL container and does not support iterator.
Similar to vector <bool>, it uses a compressed representation so that each value occupies only one space. It provides a special member function of vector <bool> and also contains
Special member functions of a series of collection of bits. If you don't care whether there is no iterator or dynamic size, the bitset may be exactly what you want.

Now let's discuss the failed experiment of the nobility, which leaves the vector of non-STL containers in the standard library. I mentioned earlier that the Code object is in the C ++
It is very useful in programming. c ++ Standards Committee members are of course aware that they decided to develop vector <bool> As a demonstration. How does it explain STL?
Container that supports element access through proxy. 1. But this example appears in the standard, and it is described in detail. Developers will have a reference to implement their own
Proxy-based container.

However, they finally discovered that it was impossible to create a proxy-based container to meet the needs of all STL containers. For some reason, they failed and were under development.
This example is left in the standard. Maybe someone will explore the cause of the existence of vector <bool>, but in reality, this does not affect anything. What's important is: vector <bool>
Does not meet the needs of STL containers; you 'd better not use it; deque <bool> and bitset are basically able to meet your needs vector <bool> substitutes.