[MUD-Dev] Let's talk about numbers.
Jon A. Lambert
jlsysinc at ix.netcom.com
Fri Sep 25 01:59:33 New Zealand Standard Time 1998
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.
> #define ST_MAX_DEPTH 64
> * 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 ..
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:
#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
--/*\ 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 /*\--
More information about the MUD-Dev