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