[MUD-Dev] Re: Let's talk about numbers.

[T. Alexander Popiel]

In message:  <199809250559.AAA12879 at dfw-ix14.ix.netcom.com>
             "Jon A. Lambert" <jlsysinc at ix.netcom.com> writes:
>On 24 Sep 98, T. Alexander Popiel wrote:
>> 
>> I'd tend to say that no, fixed dimensional arrays are not evil, if
>> properly marked.
>
>Well in this case it seems reasonable enough.  But let me make an 
>argument for another way...
>
>At initialization, a configuration file is read that sets 
>st_max_depth to some value. Then you allocate your tree later on ..

This is good, if taken in moderation.  In fact, PennMUSH has several
dozen of these sorts of runtime configuration parameters.  There are
so many configuration parameters that we routinely get complaints
that there are _TOO MANY_.  So, to satisfy user demand, we're changing
some parameters to be fixed values in various headers, we're getting
rid of data structures that require tuning (hence the use of a red
black tree for the string table instead of a hash table), etc.

Users are finicky things; they claim to want flexibility, but what
they really want is flexibility to do what _they_ want, without
having to even think about what other people might want.  Burying
them in configurable options is a good way to make them say 'but
this isn't user-friendly!'.  This extends to people setting up
servers as well as the people playing the games.

>What about things like:
>char MudTitle[65];

The 65 should be a #define, but the limit is defendable when you
consider width limitations in things like the who list.  (Why
not just show only the first 65 chars in the who list?  Because
the who list is the only place it's visible, and why bother
storing stuff that nobody can ever see?)  (Yes, you could plan
ahead for the time when someone makes the getMudTitle() function,
but perhaps the person making that function also has a clue and
can change the storage mechanism.  Assuming that all future
programmers are idiots is what's given us bloated pieces of crap
like...)

>#define MAX_ROOMNUMS 9999

This is a runtime option, for me.

>#define MAX_STRING 80

This is a compile time option, because there are static buffers and
buffers on the stack all over the place, so that we don't thrash
malloc().  (We once had someone telling us that malloc(), free(),
and realloc() were all magical zero-cost operations.  He never got
a clue, unfortunately... we ended up just ignoring him.)

>#define FIRE_BIT 2^4

This is going from a compile time option to a runtime computed value
(NOT a user-visible option) just as soon as I get done with this
next piece of code...

- Alex