Re: #defines -> enums?

From: Mysidia (
Date: 08/14/01

> 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


  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.


   | FAQ: |
   | Archives: |

This archive was generated by hypermail 2b30 : 12/06/01 PST