Re: Comparing two vectors of bools
On Aug 2, 12:13 pm, "Bo Persson" <b...@gmb.dk> wrote:
Juha Nieminen wrote:
Rafal wrote:
fgh.vbn....@gmail.com wrote:
I know that std::vector<bool> is specialized to store individual
bools as single bits.
Actually this is considered a bit of "hack" and AFAIR it will be
removed soon (in C++0x?).
Exactly how is it a "hack" and why should it be removed? Has a
better alternative been suggested?
It's strange because it is the only container that does not
store elements of the contained type.
But it does. At least as far as client code can tell. And
bitset is in a similar situation. It's strange because it's
called std::vector<bool>, but it doesn't conform to the
documented contract of std::vector.
It also uses a proxy class for vector<bool>::reference, which
is not allowed by the standard for any other container.
Again: bitset.
The problem isn't that it's there. The problem is that it is
called std::vector< bool >, and not something else. (Or
alternatively, the problem is that the contract for std::vector
is too constraining. You can argue it both ways. But if you
take this second approach, you're going to have to change some
of the basic principles of the STL.)
The real hack is that the standard assumes that everyone
benefits from a space optimization for vector<bool> and speed
optimizations for vector<everything_else>. Why?
In many cases, the space optimization may also be a speed
optimization (because of reduced cache misses). The difference
is that this optimization only applies to vector<bool>, and that
it isn't transparent, and that there's no way of making it
transparent, given the design of the STL and the integration of
std::vector into the STL.
It hasn't been removed so far, and as its section has actually
been edited in the latest draft for the next standard, it is
unlikely to go away anytime soon. We have also seen that other
containers, like std::string and std::array, are allowed to
somewhat deviate from the general container requirements, so
why not?
Because the name std::vector gives, or should give, certain
guarantees. std::bitset has a different name, and you don't
expect it to define the same contract as std::vector, so there's
no problem with it, and there'd be no problem with an
std::dynamic_bitset, either.
I certainly would like to have some kind of bool data
container where each bool indeed takes only one bit, to save
memory.
Always, or sometimes? :-)
Well, if it's not in a container, a normal bool is fine.
My own experience is that I've never needed a vector of bool
(with the interface of vector, or something similar), but if I
did, I'd want it to behave like vector. My own experience is
that I often need something like bitset (with the interface of
bitset), but with dynamic length. Except that there is a lot
more functionality which is useful: isSubsetOf( other ), etc.;
bitset doesn't seem to be able to make up its mind what it
really is either. The result is that I still use (and actively
maintain) my pre-standard implementations, even today.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34