>
> Well this are the advantages I can think of:
> - Bitfield structures don't have the 32 bit limit, you can have as much bits
> as you like.
> - The names of the bits don't have to be special for the whole code,
> they only need to be special within the bitfield itself, so two different
> bitfield structures can have the bit 'humming' on different positions without
> problems.
> - Bitfield acces looks nicer in the code, a bitfield acces looks something like
> "if (ch->affection.blind) {" instead of "if (ch->affections | AFF_BLIND) {"
> the declaration looks like:
> #define BIT(a) unsigned a: 1 /* only 1 time in the code */
> struct bitfield {
> BIT(bit1);
> BIT(bit2);
> BIT(bit3);
> BIT(bit4);
> }
> instead of
> #define VECTOR_BIT1;
> #define VECTOR_BIT2;
> #define VECTOR_BIT3;
> #define VECTOR_BIT4;
> int bitvector;
> - Bitfields probebly are a little bit faster
>
>
> I think the fist advantage is the biggest one.
>
> A disadvantage is:
> It's a bit more difficult to make bitfields 100% sure to be portable to all
> systems.
Another disadvantage I can think of now, but could easily code a way around
it... if for some reason you needed to sort through all the bits, you
couldn't use a for loop, but as I think about it, I can't think of anywhere
in the code where it WOULD use a for loop.
Nevermind. :) I think I'll convert to bitfields myself... mch more versatile
than the current AFF_BLIND etc when you are limited to 32 bits.
One suggestion though, you have unsigned int as the bit, that takes up a LOT
more memory then a bool would. Since each bit either needs to be true or
false (boolean) using a bool a; would take 1 byte of memory per bit rather
than the 4 for an integer (is 4 right? I think a bool is 1, a char is 2, and
an int is 4 if I am correct) and the unsigned does nothing except allow it
to go higher as it does not allow for negatives.
Any insight on this?
This archive was generated by hypermail 2b30 : 12/07/00 PST