On Thursday, 2 August 2012 at 09:26:04 UTC, monarch_dodra wrote:
Well, I was just trying to figure out the rationale: The most obvious one for me being "it is much easier on the implementation".

Since the template is recursive and at the end after bit counting would know how much it needed, that doesn't seem right; far more likely just to be explicit.

One of the *big* reasons I'm against having a hand chosen padding, is that the implementation *should* be able to find out what the most efficient padding is on the current machine (could be 32 on some, could be 64 on some)

If your using bitfields, then you are going for space, and to be as small as reasonably possible. Especially important for packets of information like headers for compression, and making it compatible with C/C++'s bitpacking.

That said, something that could fix the above "problem" could be: *Bitfields are automatically padded if the final field is not a "padding field".

 Workable

**Padding size is implementation chosen.

I assume you mean by word size (size_t), meaning always 32/64bit. In that case many applicable cases would go away and be useless.

*If the final field is a "padding field", then the total size must be 8/16/32/64.

EG:
//Case 1
bitfields!(
    bool, "x",    1,
    uint,  "",    3, //Interfield padding
    bool, "y",    1
)
//Fine, implementation chosen bitfield size

It would go with a ubyte as is likely obvious, although any of the types would work.

//Case 2
bitfields!(
    bool, "x",    1,
    uint,  "",    3, //Interfield padding
    bool, "y",    1
    ulong, "",   59, //Pad to 64
)
//Fine, imposed 64 bit

//Case 3
bitfields!(
    bool, "x",    1,
    uint,  "",    3, //Interfield padding
    bool, "y",    1
    ulong, "",   32, //Pad to 37
)
//ERROR: Padding requests the bitfield to be 37 bits longs

But I'd say that's another development anyways, if we ever decide to go this way.

In the end, either explicit in size, or let it round up to the size it can accept. If you let it decide, then padding would be treated as though it's a variable (but isn't), so...

bitfields!(
    bool, "x",    1,
    uint,  "",    3, //Interfield padding
    bool, "y",    1
    ulong, "",   5,
)

the total size is 9bits, the padding forces it to 16bit afterwards. In cases like this it could easily be abused or leave it in a confusing state; So likely the padding would have to be missing (and assumed) or explicit in size. So

previous one would err, while:

bitfields!(
    bool, "x",    1,
    uint,  "",    3, //Interfield padding
    bool, "y",    1,
// void, "", 4 //implied by missing, if padded and final size not ^2 would statically assert.
)

Reply via email to