[boost] Re: Proposal: cartesian_product algorithm and a finitestatemachinetemplate library

From: Marc Jacobs (marcja_at_[hidden])
Date: 2002-10-30 13:45:33

"Ihsan Ali Al Darhi" <iad929_at_[hidden]> wrote in message
news:00b701c27bbf$0e5a3cc0$73c621d4_at_iqbalubybdt9fy...
> > The second proposal is for a finite state machine template library.
Using
>
> AFAIK, there are two types of FSM. Which one are you going to build?

The finite state machine template library (aka fsmtl), as it is currently
written, provides a more convenient representation for Mealy state machines
(those whose emphasis is on the effect of transitions given the current
state) than for Moore state machines (whose emphasis is more squarely placed
on the states themselves). That said, Mealy and Moore machines are
congruent, and one can always be converted to the other.

The design goal was to able to tie finite state machine logic to business
logic without either having to move business logic code into a FSM class
hierarchy or corrupt business logic code with explosion of FSM logic code.
The fsmtl::state types, as they currently stand, are merely conveyers of
type -- they maintain no application-specific state and have no members. The
state machine itself only maintains the current state of the machine; no
application-specific state is stored there either. Application-specific
state is maintained in classes written be the library user.

A common strategy for using this kind of state machine is raise an event
before doing some work to see if the work is allowed in the current state.
Example:

void BusinessObject::turnPowerOn() {
    try {
        context::raise( fsmtl::event< fsm::poweron >() );
        // do work for turn the power on
    }
    catch( fsmtl::exception & e )
    { ... }

If the transition is not permitted given the current state and event, an
exception is thrown and no work is performed. Whether the exception is
rethrown, not caught, or translated into a different kind of exception is up
to the library user.

Alternatively, one could put more of the code into the transition templates
(see example from earlier in the thread). This is an approach that would be
more invasive on the application design.

A more Moore-like state machine can be accomplished by using the fsmtl like
a dispatching callback mechanism, that is, the application raises a generic
"do" event and the fsmtl calls back into the library user's class with the
appropriate do_xxx() member for the given state.
Marc