Hacker News new | past | comments | ask | show | jobs | submit login

D just went ahead and implemented bit fields. They work, and it's hard to find any way to improve on them.



It's hard but they aren't perfect. You shouldn't rely on them for packing memory at all if you want to talk to other programs.

Similarly bitfields mean you end up with "ints" that are actually 3 bits wide and so on.


> You shouldn't rely on them for packing memory at all if you want to talk to other programs.

While the layout is indeed implementation dependent, pragmatically if you stick to using ints the layouts are portable as far as I can tell. Just like the size of ints is implementation dependent, but is reliably 32 bits on 32 and 64 bit machines.


It also specified the layout (little endian) and disallowed reordering / padding / etc.


How bitfields are allocated within a byte is related, but independent from endianness.

endianness: how an array of bytes is interpreted as an integer/how an integer is layed out in memory as an array of bytes.

bitfield allocations: how subsequent bitfields are allocated within an integer, typically starting from least significant bit to most significant, or the other way around.


Fair, and a good point.

In this particular case, the two are related, because the LSBit-first bitfield allocations can spill over between bytes, giving LSByte-first endianness as well.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: