Re: CON_ replacement

From: Henrik Stuart (
Date: 01/10/02


> Replacing CON_ states with functions:
> On a recent project in which I built a very bare-bones
> MUD (about 2500 lines), instead of using CON_ states
> I gave descriptors a pointer to a parser function which
> is passed their input once they issue a command.  I found
> this to be much cleaner than the nanny() function.


> Blaize

   Personally I went on about the about same idea for a threaded c++
   mud I've been toying with for the past month or so, however, since
   you were used the infamous c++ word in your example (not that your
   sample doesn't look like c code an awful lot - I really hate and
   shun define stuff in c++ programs), the following might be a good

   1) Create your connection handler as a pure-virtual base class (for
   instance a class Handler that contains the functions parse and
   getName, or whatever your needs might be).

   2) Use a handler stack to manage your handler objects. Let's assume
   a person is connecting, we push the ConnectionHandler (derivative
   of Handler) onto the stack which is used in the command-parse loop.

   3) Now the matter of whether to keep adding handlers to the stack
   as the character progress through the connection phase is present.
   Personally I choose to remove the handler on the stack and add the
   new handler, since this preserves memory.

   Now, as you mention, the main benefit with this is handling editing
   strings, as well as particularly the OLC, which is a lot cleaner
   than the equivalent c versions in the circle code. However, circle
   isn't in c++ for the time being, and there are a few discrepancies
   in the circle code that should make any standards-conforming c++
   compiler fail on compiling the files as c++ files. :o)

   Anyway, that aside, I much prefer my stack handler to the CON_
   stuff. Look, for an example at adding a handler:

   ACMD(do_editinstantiation) {
     ch->desc->pushHandler(new RoomEditor(vnum));

   and equiv. code called in the routine normally managing all the
   CON_ stuff: d->runHandler(argument); (d being the descriptor).

   This, obviously, gives the benefit that you would never have to
   touch nanny or like functions handling states. (Just call the
   pop-routine in your destructor of your handler) :o)
   Another benefit is that you don't have to abide with all
   string-editing having to be of type char**, but could for instance
   be std::string& (gotta love not having to manage all the memory for
   editing strings).

Yours truly,
  Henrik Stuart (

   | FAQ: |
   | Archives: |
   | Newbie List:   |

This archive was generated by hypermail 2b30 : 06/25/03 PDT