bitfields considered harmful?

[Marcus Hall]

In article <340011 at hplvli.HP.COM> boyne at hplvli.HP.COM (Art Boyne) writes:
]>sme at computing-maths.cardiff.ac.uk (Simon Elliott) writes:
]>In article <1473 at uwbull.uwbln.UUCP>, ckl at uwbln.UUCP (Christoph Kuenkel) writes:
]>> I like [bitfields] cause they save space and are much more readable than 
]>> oriing/anding with # defines and i dont have to bother with questions like
]>> how many flags fit into one int.

]>Well, you may be right about readability, but I don't think you'll find that
]>you've saved much space in your program.  Oh, you might save it in the
]>source, but the same shifting and masking is going on under the hood.

]Whoa!  Whether or not the shifting and masking takes place depends on the
]processor you are running on.  With the 68000, single bit bitfields can
]be handled with the BCLR, BSET, BCHG, and BTST instructions.  The 68020
]has a set of multi-bit bitfield instructions for insertion, extraction,
]and testing.
]
]PS. I know that, internally, the processor is still doing shift/mask, but
]it isn't taking up my code space!

All the compilers that I have worked on can easily optimize shifting and
masking operations into bitfield operators.  It isn't really very hard to
catch most all cases, anding or oring with a constant is a good indication
that the optimization should be looked for.

Machines that don't have explicit bit operations often have to do as much
optimization to get decent performance out of bitfields.  Many times the
bitfield operations are broken, or have bad optimization (as has been
pointed out already).

marcus hall