Well actualy you hit the hammer on the nail. You need to sort through all the bits when you want to display them (stat, ident) or when you load a vector from a world file. In fact it's the same disadvantage as the one I mentioned. You can sort through the bitfields by converting them back to an array of chars (bytes), this is the easiest way but it isn't garanteed to be portable to all computers (but then again hardly anything is) Or you can make cases for al bitfield structures, which is sure to be portable but a lot of work. The secret of the bitfields is the :1 This will make the unsigned int take only 1 bit in memory (as long as you put it in a struct along with some other :1 bitfields). A bool is a typedef for a signed char in circle so a char and a bool are different names for the same thing (both 1 byte usualy). So bitfields can take up to 8 times less memory than bools. Unsigned does exactly what you say it does (no negative, more positive numbers). In a signed something the sign takes up 1 bit so something signed needs to be at least 2 bits (1 for the value, 1 for the sign), that's why a bitfield of 1 bit needs to be unsigned. Jaco On Fri, 8 Mar 1996, Hades wrote: > > 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