bitfields - Padding needed?

[Era Scarecrow]

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.
)