Why must bitfields sum to a multiple of a byte?

[monarch_dodra]

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. The developer just knows how he wants to pack 
his bits, not how he wants to pad them. Why should the developer 
be burdened with figuring out what the optimal size of his 
bitfield should be?

By leaving the field blank, *that* guarantees portability.