Quoting Robert Masten <RobertM@FOXRACING.COM>:
> > Changing it is easier now, but not impossible later. Sooner or later you'll
> > run out of room in one of the bitvectors and you will have to figure out a
> > solution.
>
> Just for the sake of conversation, why hasn't
> the base circle code moved to
> bitvectors for aff, prf, mob, etc? And moved to
> long values for vnums?
>
> Is this just a 'memory used' issue?
Partially. Way back when CircleMUD was running on the
machine 'circle' (trivia: how did CircleMUD get it's
name) at JHU, Jeremy was allowed to run the server as
long as he kept under a certain resource usage limit.
Because CircleMUD 3.0's beta stages have been 'house-
cleaning' rather than 'feature-writing', CircleMUD is
still written with that ceiling in mind.
To clarify your question, you're asking why CircleMUD
doesn't move to _128_ bitvectors, as all those flags
are already bitvectors. The quickly recognizable
alternative is bitfields, where an array of ones and
zeros stand in place of using bits. Example.
int bitv_flags; /* 32-bit integer, 32 bitvectors. */
byte bitf_flags[32]; /* array of 32 bytes, one/zero. */
#define BITV_DEAD (1 << 0)
#define BITV_ALIVE (1 << 1)
#define BITV_FLYING (1 << 2)
#define BITF_DEAD 0
#define BITF_ALIVE 1
#define BITF_FLYING 2
#define BITV_FLAGGED(bit) (IS_SET(bitv_flags, (bit)))
#define BITF_FLAGGED(bit) (bitf_flags[(bit)])
Note that, in this case, the usage denotes that
bitf_flags[] is using far more memory than bitv_flags,
because C doesn't have a boolean type, for true/false.
Bitfields assumes that zero is false, and non-zero is
true (as does all C true/false comparisons).
Note that you're limited to a certain number of
bitvectors for the first case, but you can use an array
of whatever size you want for bitfields. The ever-
popular 128-bitvectors simply uses an array of
integers, and uses the bits of each one (4 * 32 = 128).
In practice, the lack of a boolean type for bitfields
could provide more functionality to using this method,
because you can have different degrees of a bit
represented. Example.
if (BITV_FLAGGED(BITV_FLYING)) {
/* do flying stuff. */
}
if (BITF_FLAGGED(BITF_FLYING)) {
/* we know that bitf_flags[BITF_FLYING] is non-zero */
/* we can do different things based on the data */
/* that is there. */
}
In any case, there were wars, as I recall, over which
was better, 128 bitvectors, or bitfields. Neither.
Use whatever fits best. I put out an OLD version of
Oasis with 128 bitvector support, and a couple bugs.
If you read the code, the differences for 128
bitvectors is unnoticeable. If you use bitfields,
except for a potential pwipe (if you don't convert your
pfiles), all the differences can be contained quietly
in structs.h, and a few macro alterations in utils.h.
-k.
--
+---------------------------------------------------------------+
| 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