I'm working with a user-defined quantity of bits (I'm holding a three-dimensional array of bits, so the size increases cubically - assume no less then 512 bits), and need to flip them each individually. Right now, just on a computer, I'm using the bool type, since memory isn't an issue. I do plan to move the code to a microcontroller in the future, and so processing power and memory requirements may be an issue. Right now though, I just want speed.
I then found the std::bitset object from the C++ STL, but I can't define a bitset's size at runtime. I then found that the std::vector<byte> has a special initializer to store them as bits (instead of entire bytes, or 4 bytes) but then found this section in Wikipedia:
The Standard Library defines a specialization of the vector template
for bool. The description of this specialization indicates that the
implementation should pack the elements so that every bool only uses
one bit of memory. This is widely considered a mistake. [...] There is a general consensus among the C++ Standard Committee and the Library Working Group that vector<bool> should be deprecated and subsequently removed from the standard library, while the functionality will be reintroduced under a different name.
Now, you can probably see my want for using a vector<bool> object, but after reading that, I'm considering using something else. The only problem is that I'm not sure what to use. I was curious though why they state that the functionality should be re-introduced (albeit under a different name).
So, my question is, would the use of vector<bool> objects be acceptable (being that they are a part of the STL)? Are they a part of the C++ standard?
If their use is not acceptable, is there an acceptable, alternative solution (outside me defining a special container myself)? I have a few ideas myself, but I'm just curious if anyone has a better solution. Also, I would like to avoid using large libraries (again, I want to eventually port this code to a microcontroller).
There's nothing wrong with vector<bool>, except that it isn't equivalent to a vector<T> were T is the integer type equivalent to bool. This only shows in performance (CPUs only access bytes at a time, where in a vector<bool> every element is stored in one bit) and memory access (a reference to a first element of a vector<bool> is not equivalent to an array like with any other vector<T>.
It is part of the Standard, unfortunately: see section 23.3.7 (C++0x FDIS).
In "Effective STL," Item 18, Scott Meyers recommended: "Avoid using vector< bool >.":
As an STL container, there are really only two things wrong with
vector< bool >. First, it's not an STL container. Second, it doesn't
hold bools. Other than that, there's not much to object to.
The critique is that vector<bool> is the only standard container that doesn't fully conform to the standard's container requirements. That's a bit of a surprise.
Another point is that vector<bool> forces a space optimization on everyone (by storing bits), when perhaps some users would have preferred a speed optimization.
Other than that, the major deviation is that the container cannot return a reference to its members, because it doesn't store any bools. That will make the odd standard library algorithm fail to compile for vector<bool>.
If you can live with that, and it fits your needs for everything else, it is quite ok to use it.
There is boost.dynamic_bitset which is nearly identical to std::bitset, except that its size is given at runtime. If you're not interested in boost dependency, its source code (which is entirely contained in its header file) could at least give more ideas on how such container could be written.
There's nothing wrong with correct usage of vector<bool>, just like there's nothing wrong with auto_ptr- as long as you know the drawbacks and the surprises before going on.
I would suggest using the BITSCAN library, as an alternative to Boost:dynamic_bitset. A comparative survey can be found here.
An alternative could be BitMagic although I'm not sure it works on any other architecture than x86(it's heavily optimized using SIMD).
