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

[Oliver Jowett]

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

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 */ } 

ADD_COMMAND(name_command);


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.

-O