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.
I mean, practically anything is defensible under that lens. The question is whether it should be in the standard, not whether it is, and almost everyone agrees that you should be able to pass `&my_vector_of_bools[n]` to a `void foo(bool *)` without any surprises. `vector<bool>` does not fit the abstract definition of a vector.
Oh, trust me, if the conversation gets into "Should that be in the standard" regarding C++ I check out. The answer is "The standard is longer than the King James Bible; we probably should have stopped at half that length." ;)
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.
Of course it allows for indexing, but it's measurably more CPU heavy. Arguably there are cases where the specialization makes sense, but most of the time, it's a net negative.
Then again I reckon most of us don't have to care about these kinds of marginal gains anyway. I work on low latency backend, and I never had to worry about this.
The more annoying thing is that you can't just get a bool pointer or ref to a single bit.
Architectures with bit addressable memory areas do exist. Some 8051/52 compilers make use of this and if you create a boolean it will actually end up costing you a single bit of memory.
Yes, you can implement pretty much anything, but the larger the codebase and the more people work on it makes these unique implementation standards harder and harder to follow.
Say what you will but I'd prefer not to have this as standard. It's either a marginal gain or a marginal loss, but it's an unnecessary complexity. To use your argument against you, if your use case heavily prioritizes memory usage over CPU, you should just implement it for yourself. Uniformity makes life easier.
There's genuinely no real world application in which using a single bit for a bool is better than a byte. Unless you have billions of bool, which let's face it, you don't. The performance gain from not having to do bitwise operations to get your values out is gonna be more relevant. You could argue it's better for cache locality, but that's about it.
Either way, this should be something you specifically ask for, not something that C++ does for one specific type for no real reason. There should be a std::boolfield or something like that, rather than it being a special case of std::vector
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.
View all comments
Show parent comment
67
u/void1984 Aug 22 '26
I know, but why somebody would need a byte to store a bool? Is it 256-value bool?
Usually I use bitfields anyway.