> Distinct bit vectors vs integer type
This. I always find bitwise operations an unneeded exercise in mental gymnastics.
On the other hand, I wonder if a lot of the other quirks about numbers could be handled via a library?
This. I always find bitwise operations an unneeded exercise in mental gymnastics.
On the other hand, I wonder if a lot of the other quirks about numbers could be handled via a library?
Great characterization! I’ve always been confused why most languages don’t have better tools for bit vectors. They’re incredible common and it’s really confusing to have to use the underlying representation of numbers to do anything with them.
1. No dynamic resize, have to know size at compile time or allocate based on max expectations. And yes, std::vector<bool> sucks too.
2. Despite being only statically sized, several classes of bugs are not prevented at compile-time. For example:
std::bitset<4> fail1{"10001"}; // This produces a value of 0b1000, no warnings or exceptions thrown
std::bitset<10> fail2; fail2.set(11); // Exception at runtime. Why is this not a static_assert?
3. Size is implementation defined. std::bitset<1> can use up to 8 bytes depending on compiler/platform.
4. Debug performance is 20x slower than Release. In many cases you are going from what would be a single assembly instruction to multiple function calls.
5. Limited options for accessing underlying storage efficiently (for serialization, etc). to_ullong() will work up to 64 bits, but beyond that it will throw exceptions.
6. Uses exceptions. This is still a deal breaker for many.
7. Cannot toggle a range of bits at once. It's either one or all.
(But actually a ton of other stdlibs do have one too.)