2 ms·
This code would be less bullshit if C language (or C+ or any successor) enabled bit arrays and slices, just like byte arrays work. Bit-fiddling grows from the f
by wruza 5y ago
This code would be less bullshit if C language (or C+ or any successor) enabled bit arrays and slices, just like byte arrays work. Bit-fiddling grows from the fact that there is no “addressable bit sequence” type in a language. I wonder how many bugs could be erased by simply allowing the following in such algorithms:
bit data[length];
int width = 6;
bit value[width] = random(64);
for (i=0; i < lim; i += width) {
int j = endof(i, width);
data[i:j] = value;
}
or something like
uint8_t c = 0xff;
c[0..3] = 1;
c[5..7] = 1;
// c == 0x31
- jrockway 5y agoI recently wrote a microbenchmark where I convinced myself that doing operations to a [64]bool was equally fast as doing the same (bitwise) operations on an int64.
- dgunay 5y agoC++ has `std::bitset` for when the length is known ahead of time [0]. Otherwise, `std::vector<bool>` _may_ be specialized to occupy one bit per element [1]. [0]: https://en.cppreference.com/w/cpp/utility/bitset https://en.cppreference.com/w/cpp/utility/bitset [1]: https://en.cppreference.com/w/cpp/container/vector_bool https://en.cppreference.com/w/cpp/container/vector_bool
- wruza 5y agoBoth (and boost’s version too) can only address/assign one bit at a time, so it introduces the mirrored problem: how do you splice an n-bit integer into it without fiddling? Of course one can always abstract ops from my snippet away into some library, like setbits(ptr, offset, len, value), that’d be still valid, no need for fancy overloads even. But when batteries aren’t included, nobody cares enough to buy them separately. We know that from the situation with C strings.