4 ms·

The case where a) you don't care about the in-memory representation of your struct and b) you care a lot about being able to pack into the absolute minimum memo

The case where a) you don't care about the in-memory representation of your struct and b) you care a lot about being able to pack into the absolute minimum memory space, but not enough to make sure the compiler actually packs the fields (depending on architecture and optimization settings, they might not!) is vanishingly small. The more frequent perceived use for bit-fields (in the situation where they actually work) is to pack into a serialized data format, such that memory or a data stream can be accessed elsewhere. In that case, "the compiler can do whatever it wants with your data packing" is pretty useless, since your "elsewhere" might have a different compiler that does a totally different thing.

dmitrygr 5y ago
> is vanishingly small. Ladies and gentlemen, this thought is why we now consider 8GB of ram to be a "weak device". No, no no no no, 1000 times no. Every situation is a low ram situation. Every!
- InitialLastName 5y ago
  What I'm saying is that the case where you want to use less RAM for a bit field but you don't actually care if the compiler allocates less then an addressable line of RAM for that bit field (because it actually just might not) is pretty empty. Edit: I know it's hard to read a whole sentence at once, but I made that same point directly up there too.
dfox 5y ago
Optimization settings should not affect memory layout as that is specified by ABI (and large part of the “art of structure packing” is about manually reordering struct fields because the compiler cannot do that however obvious the optimization would be). And as for the second part: anything that writes sizeof(struct foo) bytes of struct foo is inherently non-portable. If you portably want to (de)serialize something you want to write the thing explicitly, very often the compiler will optimize it to more direct implementation. (And well, this is only portable to platforms where CHAR_BITS == 8)
- ncmncm 5y ago
  The operative word is "should". Anything that affects the actual instructions executed on the actual chip they're executed on may make what works here not work there. Optimization that does not affect instructions is no optimization at all. Bitfields are an extremely fragile part of implementations. Trust it at your own risk.

dmitrygr 5y ago

> is vanishingly small. Ladies and gentlemen, this thought is why we now consider 8GB of ram to be a "weak device". No, no no no no, 1000 times no. Every situation is a low ram situation. Every!

InitialLastName 5y ago
What I'm saying is that the case where you want to use less RAM for a bit field but you don't actually care if the compiler allocates less then an addressable line of RAM for that bit field (because it actually just might not) is pretty empty. Edit: I know it's hard to read a whole sentence at once, but I made that same point directly up there too.

dfox 5y ago

Optimization settings should not affect memory layout as that is specified by ABI (and large part of the “art of structure packing” is about manually reordering struct fields because the compiler cannot do that however obvious the optimization would be). And as for the second part: anything that writes sizeof(struct foo) bytes of struct foo is inherently non-portable. If you portably want to (de)serialize something you want to write the thing explicitly, very often the compiler will optimize it to more direct implementation. (And well, this is only portable to platforms where CHAR_BITS == 8)

ncmncm 5y ago
The operative word is "should". Anything that affects the actual instructions executed on the actual chip they're executed on may make what works here not work there. Optimization that does not affect instructions is no optimization at all. Bitfields are an extremely fragile part of implementations. Trust it at your own risk.