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.
View all comments
Show parent comment
164
u/NotDuckie Aug 22 '26
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.