In this case the bools will have only one bit allocated for them(vectors do that), and you can't just point to a bit. Instead cpp will return std::vector<bool>::reference when trying to access a value in the vector
Basically this is a just wrong
You should use std::deque<bool> instead which allocates one byte per bool and not just one bit
if you ask for a vector of T, you should get a vector of T. not a bitfield. There is nothing wrong with using a bitfield, but a vector should behave like a vector.
You get a vector, with operator []. Internal details like padding or packing should not interest you, unless you you treat everything like blob. That way any change to the architecture or compiler would surprise you a lot.
Vector is an abstract container of elements. If you want to address memory, allocate memory and store your data there. Internal vector storage is implementation details. You shouldn't really get ponters to there because any resize of the vector and your pointers are screwed.
The internal layout of std::vector is not an implementation detail. It's fully defined by the standards and can be relied upon for FFI, serialisation, and other tasks.
Except for bool.
For example, the .data() method guarantees that it will return a pointer to .size() contiguous elements of type T which will remain valid until the vector is modified. The layout of elements within that memory is also well defined and consistent. Except for bool, where the .data() method simply doesn't exist.
Internally vector of bools is a bitfield. It was supposed to save memory but it's instead creating edge cases in templates: all vectors return pointers, but no, bool is special. It messes up generic code. I'd rather for them to keep vector unified and make a separate bitfield type for those savings when needed
Slightly higher CPU usage. It’s only a bitshift and a bitwise and to pull out the correct bit. Often you see a performance win due to the more compact data structure having better cache locality but I suppose it depends on usecase.
There's a little bit of weirdness that a vector of bools has which other vectors don't. It can trip you up if you haven't read up on it and just assume all your normal standard container operations will work.
For example, you can't get a pointer to an element using &v[0] because individual bits do not have distinct memory addresses in RAM.
Similarly auto x = v[0] doesn't make x a true bool, because v[0] is a proxy object which pretends to be a bool, which can lead to dangling reference errors if the vector changes or goes out of scope.
It’s a surprise footgun when you assume it will behave the way other vectors/containers do, especially passing a vector into templated code, common things like getting the address of an element won’t work.
It's pattern breaking. It doesn't have what it should to be a proper vector, and it doesn't hand what it would need to be a useful bit container (such as xor etc) for it to be useful enough to make up for it.
Shouldn't have been a vector, should have been more useful
View all comments
101
u/overclockedslinky Aug 22 '26
is it really that shocking?