On 8/2/12 9:48 AM, monarch_dodra wrote:
> On Thursday, 2 August 2012 at 12:38:10 UTC, Andrei Alexandrescu wrote:
>> On 8/2/12 5:26 AM, monarch_dodra wrote:
>>> 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)
>>
>> In my neck of the woods they call that "non-portability".
>>
>> If your code is dependent on the machine's characteristics you use
>> version() and whatnot.
>
> Well, isn't that the entire point: Making your code NOT dependent on the
> machine's characteristics?
>
> By forcing the developer to chose the bitfield size (32 or 64), you ARE
> forcing him to make a choice dependent on the machine's characteristics.

I think that's backwards.

Andrei

On Thursday, 2 August 2012 at 14:52:58 UTC, Andrei Alexandrescu wrote:
> On 8/2/12 9:48 AM, monarch_dodra wrote:
>> By forcing the developer to chose the bitfield size (32 or 64), you ARE forcing him to make a choice dependent on the machine's characteristics.
>
> I think that's backwards.

 I think specifying bitfields, you're already going really low level; meaning you need explicit and full control. As for portability, if the size is specified, it comes down to endinness or order of the fields.

Zlib header: http://tools.ietf.org/html/rfc1950

A zlib stream has the following structure: CMF, FLaG

CMF:
    bits 0 to 3  CM      Compression method
    bits 4 to 7  CINFO   Compression info
FLaG:
    bits 0 to 4  FCHECK  (check bits for CMF and FLG)
    bit  5       FDICT   (preset dictionary)
    bits 6 to 7  FLEVEL  (compression level)

This easily becomes:

//assumes small-endian
mixin(bitfields(
    ubyte, "CM", 4,
    ubyte, "CINFO", 4,
    ubyte, "FCHECK", 5,
    ubyte, "FDICT", 1,
    ubyte, "FLEVEL", 2)); //should be exactly 16 bits

 Now if a typo was done (wrong number of bits) or endianness is questionable, this becomes completely different as the fields could be as much as 3-7 bytes off (24 bits, or worse if it assumes 64bits, 56 bits off), or cover a much larger area than it should for the bits. This is unacceptable, especially if you need to get low level with the code.