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

[Jon A. Lambert]

On 24 Sep 98, T. Alexander Popiel wrote:
> In message:  <199809240523.AAA14210 at dfw-ix10.ix.netcom.com>
>              "Jon A. Lambert" <jlsysinc at ix.netcom.com> writes:
> >
> >I agree,  we should always attempt an implementation  in terms 0, 1 
> >and many(unknown/infinity/X).  There are exceptions and instances 
> >where we must pay homage at some level to the failings of our 
> >silicon, but these should be rare and abstracted if possible.   
> >
> >It begs the question, "Is the fixed dimensional array evil?"
> 
> I'd tend to say that no, fixed dimensional arrays are not evil, if
> properly marked.  I submit these excerpts from the string table code
> I mentioned a few posts ago as my defending argument:
> 
> /* This is a string table implemented as a red-black tree.
[snip]
> #define ST_MAX_DEPTH 64
[snip]
>  * The fixed size of this array puts a limit on the maximum
>  * size of the string table... but with ST_MAX_DEPTH == 64,
>  * the tree can hold between 4 billion and 8 quintillion
>  * strings.  I don't think capacity is a problem.
>  */
> static StrTree *path[ST_MAX_DEPTH];
> 

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 ..

StrTree *path;
path  = (StrTree *) malloc(st_max_depth);

Like I said in this case, it may not be reasonable.  OTOH, There are 
cases where one wants to configure a minimum capacity due to storage 
constraints.  Or perhaps wants to tune a cache.  You force an issue 
where changes to a system require a re-compile.  

What about things like:
char MudTitle[65];
#define MAX_ROOMNUMS 9999
#define MAX_STRING 80
#define FIRE_BIT 2^4

I certainly see where system level code must conform to hardwired 
limitations.  And where it exists, it should be localized as much as 
possible.  But why should application level code be static?  Why not 
runtime configurable?   This may not be a major issue for those 
running softcode engines like MudOS, DGD, Cold or PennMUSH since
much of the code is at this level is system level code.  Although it 
may pose maintenance issues in the softcode itself (mudlibs, dbs).  
But for hardcoded servers it is a major issue.  Yes, servers 
like Diku may have templatized the Player, the Object, the 
Room.  But the routines for processing that information are not and
are subject to some awful hardcoded limits.  This is just a design 
technique that I think it's wise to pay close attention to when 
writing code.

--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--