bit fields

Walter Bright newshound2 at digitalmars.com
Sat Aug 28 08:20:25 UTC 2021


I have been working on implementing bit fields for #ImportC, with invaluable 
help from Iain.

And I've learned an unexpected lesson. Bit fields with DMC and Microsoft VC are 
simple. Bit fields on clang and gcc are complicated and messy. I've had a hard 
time duplicating that behavior. Hence,

1. https://dlang.org/phobos/std_bitmanip.html#bitfields does not create bit 
fields that match gcc/clang behavior. Not at all.

2. It's unreasonable to expect users to figure out how to lay out bit fields. 
Heck, how gcc/clang do it is essentially undocumented. They should be able to 
use bit fields that "just work" with the associated C compiler. We should be 
doing the hard work of compatibility, not dumping it on users.

3. DasBetterC is not in a great place since it can't do matching bit fields.

4. D is supposed to have relatively seamless compatibility with C. But we've 
left users twisting in the wind with C bit fields.

But there is good news. The result of figuring out bit fields for ImportC is 
that the logic is already in the D compiler, and we merely have to "turn it on" 
and it will work for D. There'll be a bit of extra work to deny trying to take 
the address of a bit field, pass it by `ref`, etc., but not too bad.

I propose adding bit fields to D to resolve these problems.

There are other advantages, too. I often use bit flags:

     enum Flags { A = 1, B = 2, C = 4, D = 8 }

     Flags f;
     f |= Flags.A;
     f &= ~Flags.B;

but this is tedious, and so this often just winds up as:

     bool a, b, c, d;

which is expensive in memory. With bit fields it is:

     bool a:1, b:1, c:1, d:1;

If we do it right, the code will be the same as the Flags version, and we can 
just do away with the Flags declaration.

P.S. Since the DMD backend already does bit fields, it was pretty simple to hook 
that up with ImportC.

Thoughts welcome.


More information about the Digitalmars-d mailing list