[MUD-Dev] Re: Question on c++ switch optimization, and parsers in general.

Oliver Jowett icecube at ihug.co.nz
Tue Feb 9 10:23:34 CET 1999

On Mon, 8 Feb 1999, Adam Wiggins wrote:

> I've always been fond of the simplicity of the "big array with everything
> you need to know about a given command" method.  Apparently some folks in
> the diku world are as well: I know that stock CircleMUD handles commands
> this way.

The problem with this is when you have a lot of command-specific
information embedded in the command. For example the parser I'm
currently working on defines the "name" command, used to give a name to
another player or NPC, as:

  { "name", "<charroom> *here [*as] <string>",      true, new_do_name_char },
  { NULL,   "(<player>|<charroom>) [*as] <string>", true, new_do_name_char },
  { NULL,   "<word> <string>", false, fail_string, "You see no %s here.\n" },
  { NULL,   "[<string>]",      false, fail_string, "Name whom as what?\n" },

Currently this is in a table with several other commands. It would be
nice, however, to have this information actually kept with the command

I'm thinking of using ELF sections for this: something like (no guarantees
if this even compiles)

#define ADD_COMMAND(x) static command_data * x ## _ptr \
   __attribute__((section("commands"))) = &x

command_data name_command[] = { /* command details here */ } 


Then the main parser can run through the "commands" section, following the
pointers to get a list of all the commands:

/* Defined by the linker, maybe - solaris doesn't IIRC, you have to
   position these symbols in the right section in .o's linked at the start
   and end of your link line
extern command_data *__start_cvs, *__stop_cvs;

command_data **p;
for (p = &__start_cvs; p < &__stop_cvs; p++) {
  /* do something with (**p) */

ELF sections are quite useful for gathering data together like this -
I've also used them to gather CVS IDs from source files at runtime.


More information about the mud-dev-archive mailing list