DIP: add Bit Fields (page 3)

On Thursday, 7 March 2024 at 22:28:34 UTC, Dennis wrote:

Why bow down to C and treat D as a second class citizen? The DIP should really substantiate this alleged importance of C-compatibility of non-ImportC D bitfields: Can you name at least one dub package that would benefit from bit fields with C-compatible layout?

Qt uses bitfields in some headers, e.g. here: https://github.com/qt/qtbase/blob/4e158f6bfa7d0747d8da70b3b15a44b52e35bb8a/src/corelib/kernel/qtimer.h#L239

My bindings emulate the bitfields with a single field and accessor functions: https://github.com/tim-dlang/dqt/blob/2afa4adcec0a6905b11256f403c6136277a6c96a/core/qt/core/timer.d#L217

Bitfields in D could be used instead, but they would need to be compatible with C++ for extern(C++) types.

Sometimes bitfield members are disabled with the preprocessor: https://github.com/qt/qtbase/blob/4e158f6bfa7d0747d8da70b3b15a44b52e35bb8a/src/corelib/time/qdatetime.h#L259
This could be translated to version statements in D.

Most of the times bitfields for Qt are not a big problem, because they are only private members of the types.

March 09

Re: First Draft: Bit Fields

Posted by Nick Treleaven
in reply to Richard (Rikki) Andrew Cattermole

Permalink

Nick Treleaven

Posted in reply to Richard (Rikki) Andrew Cattermole

Permalink

On Thursday, 7 March 2024 at 05:00:36 UTC, Richard (Rikki) Andrew Cattermole wrote:

"gdc/lcd are lumped together because they produce identical results on the same platform."

s/lcd/ldc/

No mention of alignment, total size or the offset.

Agree, the DIP should mention those. The implementation seems to give each bitfield of a set the same value:

struct S
{
    uint a:1,
         b:1,
         c:1;
}
static assert(S.b.alignof == 4);
static assert(S.b.offsetof == 0);
static assert(S.b.sizeof == 4);

Needs to mention atomics as not being supported.

Yes. Bitfield impl doesn't allow shared, static (or even const) storage classes.

No trait to detect a bit field (if its an alias, or by name), nor get its size. Kinda required, enough other things in the language can appear via an alias sequence or by allMembers that are not able to be taken as a pointer of.

Possibly this might be enough (using S above):

enum E
{
    a, b, c
}
struct U
{
    int i;
    alias i this;
    enum max = 2;
}
enum isBitfield(alias a) = __traits(isIntegral, typeof(a)) &&
    !is(typeof(a) == enum) && a.max <= uint.sizeof * 8;

static assert(isBitfield!(S.b));
static assert(!isBitfield!(E.b));
static assert(!isBitfield!(U()));

The ability to take an alias via getMember needs to be considered if its valid to do so.

No mention of tupleof either, what happens there?

Impl:

void main()
{
    S s;
    s.tupleof[1]++;
    __traits(getMember, s, "c")++;
    writeln(s.tupleof); // 011
}

No motivation for not including a D layout for it, instead of forcing everyone into an unpredictable layout that the system C compiler might be using. Moving us off the library type and into a language defined one that is predictable is quite attractive so there needs to be an argument against this.

Just to mention, the argument in the DIP was portability with C bitfields.

import std.stdio; struct S { union { uint u; uint a:1, b:1, c:1; } } static assert(S.sizeof == 4); void main() { S s; s.tupleof.writeln(); // 0000 s.u++; s.tupleof.writeln(); // 1111 }

I've had a bit of thought about the ABI concerns of having multiple layouts possible. I think its better to ignore the ABI altogether when changing it. ```d import core.attributes : bitfieldlayout; struct Foo { @bitfieldlayout("packed") { int bar:1; int zah:2; } } ``` That'll also solve how do we add new ones that isn't C or packed. C can be default, that need not be changed to something else.

On 3/11/2024 2:46 AM, Martin Tschierschke wrote: > On Thursday, 7 March 2024 at 04:26:56 UTC, Walter Bright wrote: >> https://github.com/WalterBright/documents/blob/master/bitfields.md > > Typo: >> Abstract >> This proposal is for supporting bitfields in **C** the same way they are supported in **C**. > > > haha

Forums