On Nov 16, 2010, at 1:31 PM, William A. Rowe Jr. wrote:
> On 11/16/2010 8:29 AM, Graham Leggett wrote:
>> On 16 Nov 2010, at 2:35 AM, Nick Kew wrote:
>>
>>> Well, you *could*. You'd just (probably) sacrifice the optimisation.
>>> Much the same story as a bunch of chars.
>>>
>>> FWIW, if I'd been designing the above from scratch, those flags
>>> would be a bitfield and a set of #defines, thus occupying a
>>> fixed/known width in the struct. Compared to that, using :1
>>> just enables the compiler to optimise to an indeterminate size
>>> according to its alignment rules.
>>
>> Given that v2.4 isn't baked right now, it looks like a very sensible
>> suggestion to change
>> it in this way.
>>
>> At the very least, it gives us the option to add bit fields (to a sensible
>> limit) without
>> having to stick them on the end.
>
> If we go this route, to introduce single bit flags, I'm still strongly
> opposed to
> int mbmr:1; at the very least, lets use unsigned to avoid sign extension,
> please?
>
++1...
However, I will quote Kernighan & Pike in "The Practice of Programming":
"Don't use C or C++ bitfields; they are highly non-portable and tend
to generate voluminous and inefficient code"
"Languages have dark corners where practice varies - bitfields in
C and C++ for example - and it is prudent to avoid them"
"Bitfields are so machine-dependent that no one should use them"
