> > 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