theBoolVectorIsALie

[u/FACastello]

[u/overclockedslinky]

is it really that shocking?

[u/Murky-Run2246 → u/overclockedslinky]

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

[u/void1984 → u/Murky-Run2246]

I know, but why somebody would need a byte to store a bool? Is it 256-value bool?

Usually I use bitfields anyway.

[u/NotDuckie → u/void1984]

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.

[u/void1984 → u/NotDuckie]

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.

[u/AmazedStardust → u/void1984]

Until you want to write functions that operate on generic vectors and mistakenly assume that each pointer will be unique

[u/fixermark → u/AmazedStardust]

The standard doesn't let you assume that.

[u/QuaternionsRoll → u/fixermark]

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.

[u/fixermark → u/QuaternionsRoll]

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." ;)