> If you plan to expand beyond the limit of 32 bits, you will need a
> compiler capable on handling long long variables. Those compilers (as
> far as I know) expands the enum type storage size automatically. Try it:
Long long is not something you want to use.. the problem is that it's
not portable -- only the GNU Compiler Collection's GCC has 'long long',
some others have datatypes of 64-bits but they may have other names,
but ANSI C does not require support for any 64-bit type.
Better to use a user-defined type for such things.. probably a structure
with an array of ints where size is <total bits to be available>/CHARBITS
where CHARBITS is calculated number of bits in a char (at least 7 bits)..
operations would be required to determine which slot/bit to manipulate,
but it could be done pretty simply assuming the rest of the code didn't
make an assumption that locks you into a certain way of doing things.
I'm merely referring to the enum {} point-of-view.. when you use constants
and make less construct assumptions outside of the constructs themselves,
implementation of extentions becomes a lot simpler.
The smaller the extention can be made, the less error-prone it probably
turns out to be... assuming the one editing it double-checks their
alterations.
Example:
A routine that needs to fiddle around with a list of objects won't
do it directly unless it's the global, standard method for making
that list tweak. (Ex: you don't just pop an item off room->contents,
throw it in ch->carrying and update all the pointers yourself...
you rely on obj_to_char to do it for you.
Similarly, you don't just use '|' when you need to combine two
sets of circle-bitvector 'flag' masks, you use a special macro devoted
to that purpose.)
Modular design is a good thing.
-Mysid
--
+---------------------------------------------------------------+
| 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/06/01 PST