3 ms·

I don't think I've ever seen struct bitfields used in real code, it's almost always manual bit-masks against a numeric type, often via macros. (I assume due to

I don't think I've ever seen struct bitfields used in real code, it's almost always manual bit-masks against a numeric type, often via macros. (I assume due to portability)

abnercoimbre 1y ago
Yep. If I need a boolean for a struct I know I’ll want more than one. So I’ll stick an integer type that lets me OR multiple enum values (and so on).
gizmo686 1y ago
I see it decently often in embedded code for memory mapped IO registers. Other than that, I don't think I've ever seen it either. I'm not sure portability is the reason though. I've seen it in places that have no problem spamming #define __GNU_SOURCE
- nomel 1y ago
  This is the only place I've seen it used, and the only placed I've used it. It's absolutely wonderful for IO.
- mort96 1y ago
  I would be scared of using it for IO... With a struct bit field, I don't know what bit offset a field ends up with, I don't know how it gets padded, and I don't know how large the generated load and store becomes. I'd rather do the bit operations and store myself.
  - gizmo686 1y ago
    __attribute__((packed)) is pretty much required for this use case.
    - mort96 1y ago
      That gets rid of the padding issue, but still does little to tell me which bit corresponds to which field.
tom_ 1y ago
In terms of the underlying bit assingments, bitfields have been pretty safe for a very long time now, as you can assume little-endian. Just a question of bearing in mind the packing rules, not too difficult given stdint.h. I went full bitfield shortly after the time I went full size_t, about 15 years ago now. Big-endian systems sort-of still exist (I do indeed have an Amiga, and an Atari STe, and an Xbox 360, and they all work, so they must count) - but they're only slightly less weird from a practical C programming perspective than stuff like the DSPs with CHAR_BIT==24, and Harvard architecture microcontrollers with 2-byte ints. And so you can ignore them. People that use still actually these systems will be used to it.
dirt_like 1y ago
I have seen bit fields used in real code. Long ago. The reason I know it so well is that bit field updates are NOT atomic, and this caused a rare crashing bug under heavy load. Unless you read the header the code looks atomic. S->buffer_free = 1; This is a very serious limitation if the structure/class is being updated in a multi-threaded environment.
ziml77 1y ago
The Windows API uses bitfields like that in some places. I know because I was working with the display configuration API recently and found the bitfields very annoying to use through generated FFI bindings (especially because they were used in anonymous structs inside anonymous unions).
ack_complete 1y ago
There are some other annoyances, like not being able to inline initialize a bitfield prior to C++20, and sometimes having to use unnatural typing to get optimal packing depending on the ABI. But I've seen them used, compilers have gotten pretty good at optimizing them and can coalesce writes or tests against adjacent bitfields.
_zagj 1y ago
I have, e.g., in Julia's UTF-8 library (utf8proc).

I don't think I've ever seen struct bitfields used in real code, it's almost always manual bit-masks against a numeric type, often via macros. (I assume due to portability)

abnercoimbre 1y ago

Yep. If I need a boolean for a struct I know I’ll want more than one. So I’ll stick an integer type that lets me OR multiple enum values (and so on).

gizmo686 1y ago

I see it decently often in embedded code for memory mapped IO registers. Other than that, I don't think I've ever seen it either. I'm not sure portability is the reason though. I've seen it in places that have no problem spamming #define __GNU_SOURCE

nomel 1y ago
This is the only place I've seen it used, and the only placed I've used it. It's absolutely wonderful for IO.
mort96 1y ago
I would be scared of using it for IO... With a struct bit field, I don't know what bit offset a field ends up with, I don't know how it gets padded, and I don't know how large the generated load and store becomes. I'd rather do the bit operations and store myself.
- gizmo686 1y ago
  __attribute__((packed)) is pretty much required for this use case.
  - mort96 1y ago
    That gets rid of the padding issue, but still does little to tell me which bit corresponds to which field.

tom_ 1y ago

In terms of the underlying bit assingments, bitfields have been pretty safe for a very long time now, as you can assume little-endian. Just a question of bearing in mind the packing rules, not too difficult given stdint.h. I went full bitfield shortly after the time I went full size_t, about 15 years ago now. Big-endian systems sort-of still exist (I do indeed have an Amiga, and an Atari STe, and an Xbox 360, and they all work, so they must count) - but they're only slightly less weird from a practical C programming perspective than stuff like the DSPs with CHAR_BIT==24, and Harvard architecture microcontrollers with 2-byte ints. And so you can ignore them. People that use still actually these systems will be used to it.

dirt_like 1y ago

I have seen bit fields used in real code. Long ago. The reason I know it so well is that bit field updates are NOT atomic, and this caused a rare crashing bug under heavy load. Unless you read the header the code looks atomic. S->buffer_free = 1; This is a very serious limitation if the structure/class is being updated in a multi-threaded environment.

ziml77 1y ago

The Windows API uses bitfields like that in some places. I know because I was working with the display configuration API recently and found the bitfields very annoying to use through generated FFI bindings (especially because they were used in anonymous structs inside anonymous unions).

ack_complete 1y ago

There are some other annoyances, like not being able to inline initialize a bitfield prior to C++20, and sometimes having to use unnatural typing to get optimal packing depending on the ABI. But I've seen them used, compilers have gotten pretty good at optimizing them and can coalesce writes or tests against adjacent bitfields.

_zagj 1y ago

I have, e.g., in Julia's UTF-8 library (utf8proc).