Re: [CODE] Whois command for C30bpl18 with ASCII

From: NeoStar (
Date: 09/10/01

> REMOVAL OF classnum VARIABLE -- The CLASS_xxx #defines are numbers.  The
> GET_CLASS(ch) macro returns a number.  CLASS_xxx are preprocessor macros
> that are convenient ways of referring to these numbers.

I thought so, but wasn't entirely sure if it would work.
> REMOVAL OF vclass[] ARRAY -- There is a global pc_class_types[] array
> defined in class.c that has the names of the classes.  It's better to use
> this array because it provides a centralized location, so that the
> addition of new classes does not require hunt-and-peck coding to fix
> other, unknown dependencies.  Also, when you add arrays of this sort, if
> they're general purpose add them to an appropriate file (class.c,
> constants.c, etc.) and, if you're going to provide an array-size, use a
> #define'd constant in structs.h or wherever for it.  This eliminates the
> dependency on magic numbers.  If you use the macro throughout, changing
> the macro suffices to make all of the code that relies upon it working.
> Compare vclass[5] with vclass[NUM_CLASSES+1].

Well the reason I did this was because the MUD I help code for has about 14
races and maybe 5 classes and the Imp wanted special strings for each
race/class combo. When I was cleaning it up to put on the mailing list, I
renamed a few variables and cut down on  a lot that wasn't needed for stock
circle. But thank you for showing me the pc_class_types :) And I still see
what you are saying with the NUM_CLASSES, etc...
> NO GLOBAL BUFFER RELIANCE -- I removed the reliance on global buffers.
> Using local space is much more safe and no more expensive: it's
> not to have unintended side-effects on other code.

Where'd I have a global buffer?

Well thanks a lot for your help, I hadn't realized I could clean it up so
much ;)


   | FAQ: |
   | Archives: |

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