You'll find attached a tarball with complete specs for what should be
the ultimate state machine implementation.  At least as far as GUII
requirements are concerned.  Some of the simpler functions are
implemented, however, the rest are still function signatures and
documentation.

Just for the record there are 181 lines of code out of 576 in
StateMachineEngine.h.  That's about 30:70 split at present.  When the
bodies of the functions are filled in it'll end up about 50:50.  There are
so many lines of code because of the way I've formatted the template
definitions.

StateMachine/
StateMachine/StateMachineEngine.h
StateMachine/StateMachinePolicies.h
StateMachine/sm-test.C
StateMachine/Makefile
StateMachine/Doxyfile

The tarball would have been half the size without the Doxyfile but as I
recommend that you run:
        make sourcedoc

on it and read everything that way this is a small price (generated html
and gifs are over 100kB).

I'd appreciate some input on the StateMachinePolicies.h implementations.
I'm not happy with the #define.  I'd like ideas for a better way to get
Continue and Ignore implemented -- read the comments for ActionPolicy to
learn more about them (they're actually implementations of ReturnPolicy).

I've considered doing the ActionPolicy<ReturnPolicy> in the reverse
manner but I don't like that much either as it'd end up something like:

template <template <class> class ActionPolicy,
          class Data
>
struct Continue
{
        bool operator() (bool assertion,
                         string const & msg,
                         Data const & data) {
                ActionPolicy<Data>()(assertion, msg, data);
                return false;
        }
};

Hmmm, maybe not quite so ugly as current.  I'm probably overusing
operator().

Allan. (ARRae)

P.S.  I don't know what Amir was talking about.  This tarball and an email
fit in less than 50kB ;-)

P.P.S.  Yes, there are a lot of template parameters but I want this to be
as flexible as possible.  We can trim it when it goes into LyX but if I'm
going to write a killer FSM implementation I want to make it complete.

P.P.P.S.  DialogController is at least another week away as I got carried
away with the state machine.  I'll get it up to a similar spec to this
before releasing it.  It's nearly there but needs revising in light of the
state machine work -- more to do with ideas I've had since I last looked
at it a week ago.

State machine specifications

Reply via email to