4 ms·

> 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

> 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?

klysm 4y ago
> unneeded exercise in mental gymnastics 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.
morelisp 4y ago
It is solved by the standard library. https://en.cppreference.com/w/cpp/utility/bitset https://en.cppreference.com/w/cpp/utility/bitset
- Scaless 4y ago
  It is not "solved" at all. std::bitset has terrible properties and an awful interface. 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.
  - deleted 4y ago
    [deleted]
- gwbas1c 4y ago
  Uhm, you know that there are other languages than c++?
  - morelisp 4y ago
    Sure, the point is that it doesn’t take language machinery to do it. And as the other post demonstrates, trying to make a standard one will mostly just get people pissed you made different tradeoffs. (But actually a ton of other stdlibs do have one too.)

klysm 4y ago

> unneeded exercise in mental gymnastics 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.

morelisp 4y ago

It is solved by the standard library. https://en.cppreference.com/w/cpp/utility/bitset https://en.cppreference.com/w/cpp/utility/bitset

Scaless 4y ago
It is not "solved" at all. std::bitset has terrible properties and an awful interface. 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.
- deleted 4y ago
  [deleted]
gwbas1c 4y ago
Uhm, you know that there are other languages than c++?
- morelisp 4y ago
  Sure, the point is that it doesn’t take language machinery to do it. And as the other post demonstrates, trying to make a standard one will mostly just get people pissed you made different tradeoffs. (But actually a ton of other stdlibs do have one too.)