Why must bitfields sum to a multiple of a byte?

[monarch_dodra]

On Tuesday, 31 July 2012 at 17:17:25 UTC, Era Scarecrow wrote:
> On Tuesday, 31 July 2012 at 16:59:11 UTC, monarch_dodra wrote:
>> Maybe the user needs a 32 bit ulong? This way the ulong only 
>> takes 32 bits, but can still be implicitly passed to functions 
>> expecting ulongs.
>
>  I would think the bug only showed itself if you did int at 
> 32bits and ulong at 64 bits, not ulong at 32bits.

No, the bug shows itself if the first field is 32 bits, 
regardless of (ulong included).

I would add though that requesting a field in bits that is bigger 
than the type of the field should not work (IMO). EG:
--------
struct A
{
     mixin(bitfields!(
           ushort, "a", 24,
           uint,    "",  8
         )
     );
}
--------
I don't see any way how that could make sense...
But it *is* legal in C and C++...
But it does generates warnings...

I think it should static assert in D.

On Tuesday, 31 July 2012 at 17:21:00 UTC, Era Scarecrow wrote:
> On Tuesday, 31 July 2012 at 17:17:43 UTC, Timon Gehr wrote:
>
>> (Also IMO, the once-in-a-year wtf that is caused by 
>> accidentally assigning in an if condition does not justify 
>> special casing assignment expressions inside if conditions. 
>> Also, what is an useless compare?)
>
>  I've noticed in my experience, DMD gives you an error if you 
> do a statement that has no effect; IE:
>
>  1 + 2; //statement has no effect
>  a == b;//ditto

That's part of the standard: Statements that have no effect are 
illegal. This is a good think, IMO. I've seen MANY C++ bugs that 
could have been saved by that.

Regarding the assignment in if. I think it is a good thing. D 
sides with safety. If you *really* want to test assign, you can 
always comma operator it.

--------
void main()
{
   int a = 0, b = 5;
   while(a = --b, a) //YES, I *DO* want to assign!
   {
     write(a);
   }
};
--------I'm sure the compiler will optimize away what it needs.