5 ms·

I don't know why you haven't come across them but personally I've used bitfields a lot over my career as a video game programmer at different companies. You can

I don't know why you haven't come across them but personally I've used bitfields a lot over my career as a video game programmer at different companies. You can have arbitrary bit width integers as well. It's not really very different to zig.

flohofwoe 4y ago
> You can have arbitrary bit width integers as well. This is news to me, how? AFAIK they'll only eventually make it into C23 with _BitInt(N). ...and apart from building a C++ wrapper class of course, but how would this pack with data outside the class - like the 4 + 28 bits example in the blog post. Also IIRC when I tinkered with C/C++ bitfields, some compilers (at least MSVC I think?) didn't properly pack the bits (e.g. a single bit would be padded to a full byte, or they couldn't agree on a common size of the containing integer - e.g. one compiler packing <8 number of bits into an uint8_t, and another into a uint32_t). In the end C/C++ bitfields weren't all that useful for the use case described in the blog post, at least if portability across the three big compilers is needed (gcc, clang, msvc).
- shultays 4y ago
  Maybe other members in same struct was enforcing such packing? Such as https://godbolt.org/z/8G4v8McsP https://godbolt.org/z/8G4v8McsP You probably want static asserts for sizes in your code if you are trying to optimize your struct paddings
  - flohofwoe 4y ago
    Could also be that MSVC has improved in this area. I think I experimented with VS2015 (since this was my 'base line compiler' at the time).
- jeffreygoesto 4y ago
  The order of a bitfield is explicitly implementation defined, at least in C++ [0] and C99. I have been bitten by this when compiling bit-fiddling code with a different compiler (for the same platform). [0] section "Notes" in https://en.cppreference.com/w/cpp/language/bit_field https://en.cppreference.com/w/cpp/language/bit_field
  - shultays 4y ago
    Interesting, I saw some low level code that assumes that bits are neatly packed. Some C decisions really confuses me. What would be the point of this one?
    - layer8 4y ago
      The alignment restrictions for memory accesses on some architectures may prevent bitfields from crossing certain address boundaries, hence implementations may need to reorder and/or pad the fields. The alternative would have been to either fail compilation for bitfield combinations that are incompatible with the target platform, which would arguably be worse, because you couldn’t portably use bitfields at all then, or to force implementations to generate code with case distinctions, possibly depending on the actual alignment at runtime, performing the bitfield accesses using multiple memory accesses if necessary.
- yyyk 4y ago
  >when I tinkered with C/C++ bitfields, some compilers (at least MSVC I think?) didn't properly pack the bits There's #pragma pack for that.
- bananaboy 4y ago
  My apologies, I may have misunderstood what OP meant! I thought they assumed bitfields were always 1-bit in size. BitInt looks neat. It sounds kind of like a bit array which we use quite a lot (which is as you suggest a class wrapper over an array of uint32_t templated on a size). We use bitfields quite a bit across clang and MSVC targeting mobile, PC, and console, and haven't had any problems as far as I know.

flohofwoe 4y ago

> You can have arbitrary bit width integers as well. This is news to me, how? AFAIK they'll only eventually make it into C23 with _BitInt(N). ...and apart from building a C++ wrapper class of course, but how would this pack with data outside the class - like the 4 + 28 bits example in the blog post. Also IIRC when I tinkered with C/C++ bitfields, some compilers (at least MSVC I think?) didn't properly pack the bits (e.g. a single bit would be padded to a full byte, or they couldn't agree on a common size of the containing integer - e.g. one compiler packing <8 number of bits into an uint8_t, and another into a uint32_t). In the end C/C++ bitfields weren't all that useful for the use case described in the blog post, at least if portability across the three big compilers is needed (gcc, clang, msvc).

shultays 4y ago
Maybe other members in same struct was enforcing such packing? Such as https://godbolt.org/z/8G4v8McsP https://godbolt.org/z/8G4v8McsP You probably want static asserts for sizes in your code if you are trying to optimize your struct paddings
- flohofwoe 4y ago
  Could also be that MSVC has improved in this area. I think I experimented with VS2015 (since this was my 'base line compiler' at the time).
jeffreygoesto 4y ago
The order of a bitfield is explicitly implementation defined, at least in C++ [0] and C99. I have been bitten by this when compiling bit-fiddling code with a different compiler (for the same platform). [0] section "Notes" in https://en.cppreference.com/w/cpp/language/bit_field https://en.cppreference.com/w/cpp/language/bit_field
- shultays 4y ago
  Interesting, I saw some low level code that assumes that bits are neatly packed. Some C decisions really confuses me. What would be the point of this one?
  - layer8 4y ago
    The alignment restrictions for memory accesses on some architectures may prevent bitfields from crossing certain address boundaries, hence implementations may need to reorder and/or pad the fields. The alternative would have been to either fail compilation for bitfield combinations that are incompatible with the target platform, which would arguably be worse, because you couldn’t portably use bitfields at all then, or to force implementations to generate code with case distinctions, possibly depending on the actual alignment at runtime, performing the bitfield accesses using multiple memory accesses if necessary.
yyyk 4y ago
>when I tinkered with C/C++ bitfields, some compilers (at least MSVC I think?) didn't properly pack the bits There's #pragma pack for that.
bananaboy 4y ago
My apologies, I may have misunderstood what OP meant! I thought they assumed bitfields were always 1-bit in size. BitInt looks neat. It sounds kind of like a bit array which we use quite a lot (which is as you suggest a class wrapper over an array of uint32_t templated on a size). We use bitfields quite a bit across clang and MSVC targeting mobile, PC, and console, and haven't had any problems as far as I know.