Why must bitfields sum to a multiple of a byte?

[Era Scarecrow]

On Monday, 30 July 2012 at 23:41:39 UTC, Andrej Mitrovic wrote:
> On 7/31/12, Era Scarecrow <rtcvb32 at yahoo.com> wrote:
>> And likely one I'll be working on fairly soon. I've been 
>> concentrating on the BitArray, but I'll get more of the 
>> bitfields very very soon.
>
> Cool. What about the Max limit of 64bits per bitfield 
> instantiation? I don't suppose this is common in C++ but I 
> wouldn't know..

  The limitation is based on what kind of types you can use. If 
you want a field 1000 bits long, i don't see why not; But 
obviously you can't treat it like an int or bool. (No cheap way 
to make a BigInt here :P), and packing say a struct, it would be 
slow since it has to copy each bit individually, or if it's byte 
aligned, by bytes.

  It assumes the largest type we can currently use which is ulong, 
if cent ever gets properly added, then 128bits will become 
available. If they want to go higher than likely type 'dime' or 
'nickel' or bicent (256bits? :P) can be used once the template is 
modified. Maybe tricent can be 384 and quadcent can be 512.... 
Mmmm :) or it could just be large256, ularge256.

  As for the 'why', is that all of the bitfields work by assuming 
bit-shifting and low level binary operators to do the job. So, 2 
for 4 ints would be

int value;
int a() @property {
   return value & 0x7;
}
void a(int v) @property {
   value &= ~0x7;
   value |= v & 0x7;
}

int b() @property {
   return (value>>4) & 0x7;
}
void a(int v) @property {
   value &= ~(0x7 << 4);
   value |= (v & 0x7) << 4;
}

  That may be flawed but it gives you a basic idea.