Jeff Garzik wrote:
> <pedantic>
>
> FWIW, compilers generate AWFUL code for bitfields. Bitfields are
> really tough to do optimally, whereas bit flags ["unsigned int flags &
> bitmask"] are the familiar ints and longs that the compiler is well
> tuned to optimize.
I wouldn't have chosen the micro-optimization argument against bitfields
because people who use them as booleans will be more than willing to
trade minuscule performance degredation in non-critical paths for
heaping piles of legibility:
if (!foo->enabled)
if (!(foo->flags & FOO_FLAG_ENABLED)
No, I would have chosen the maintenance risk of forgetting that they're
really 1 bit wide scalars which truncate on assignment.
struct foo {
unsigned enabled:1;
};
int some_thing_is_enabled(thing) {
return thing->whatever & some_high_bit;
}
foo->enabled = some_thing_is_enabled()
Requiring people to remember that they want !!() around assignments
seems much more dangerous. They'll get left out to "optimize" current
behaviour, leaving land mines in the tree for future maintainers.
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |