On Wed, 21 Mar 2001, Tony Robbins wrote:
> [...snip...]
Oops, you had some things a bit off here. In the interest of ensuring
everyone's on the same page, I'll try to correct it (it may also clear up
misconceptions on your part -- or my part).
> The quickly recognizable alternative is bitfields, where an array of
> ones and zeros stand in place of using bits.
Bitfield is a term for something else. You have a byte-vector (which I
just made up based upon it being a byte-vector). Which is:
#define BIT(b) unsigned long (b) : 1
struct bitfield_data {
BIT(on_fire);
BIT(in_darkness);
BIT(floating);
BIT(spinning);
BIT(sinking);
BIT(falling);
BIT(submerged);
/* ... */
};
each of these is a single bit-wide (the ": 1" part of the declaration).
Well, in theory. In practice, it's difficult to say how your compiler and
platform will represent them.
> byte bitf_flags[32]; /* array of 32 bytes, one/zero. */
A byte is 8 bits. That's 32*8=256 bits. Doing this, you are using 8 bits
(1 byte) for every 1 bit flag you need. You'd be better to do it in
precisely the way the 128-bitvector patch does it, so that for using 256
bits, you get 256 flags. Obviously, you know this (based upon the rest of
your message), still, it bears noting.
> In any case, there were wars, as I recall, over which was better, 128
> bitvectors, or bitfields.
To summarize, the war wasn't really over which was "better," but which
provided a more complete solution. There was also the third option of
just adding a second bitvector for aff2. The debate of superiority was
mainly between these two camps: aff2 being preferred for simplicity,
aff[N] being preferred for elegand and flexibility. I don't think there
was much debate to be had over bitfields and bitvector arrays. Both can
achieve the same results, but bitfields do so in a manner that is clear
and easily extensible, whereas an array of bitvectors introduces
extraneous information and requirements that J.R. Hacker has to concern
himself with, such as the size of the array, what value you give a
particular #defined flag (the 127th flag is not (1 << 127), after all),
etc. rather than just adding the flag and having it be. For the
completeness of the solution, however, bitfields have their disadvantages:
the presumed complexity of code to write them without knowing each flag
you're writing (mainly for ASCII pfiles; you could know them all, but
that'd remove one of the principle advantages of bitfields from client
coders: that they just add the flag and that's it for that), the fact that
if you don't pad the structures you can't extend them when using binary
files with static record sizes, etc.
All of these can be addressed. I don't know about the portability of such
solutions, however, and perhaps that's where we wound up at the very end:
noting that bitfields--for all they offer--are somewhat esoteric and maybe
for a good reason (in the same way setjmp() and kin are) and maybe of
dubious portability.
-dak
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/04/01 PST