Re: finite state machine

From:

James Kanze <james.kanze@gmail.com>

Newsgroups:

comp.lang.c++

Date:

Wed, 2 Mar 2011 01:45:19 -0800 (PST)

Message-ID:

<3a62610e-ec97-4968-865f-b5c19151562a@a5g2000vbs.googlegroups.com>

On Mar 1, 9:55 pm, "dr.oktopus" <blindwi...@freeonline.zzn.com> wrote:

I am moving my first steps into the wonderful world of oop.
I have considered this approach in writing a fsm.

class fsm {
public:
        void run_fsm (void); // advance machine for 1 step

private:
        void (*state) (void);

        void state1 (void);
        void state2 (void);
        ..
};

void fsm::run_fsm (void)
{
        state();
}

void fsm::state1 (void)
{
        ..
        if (statehastochangetostate2)
                state = state2;
        ..
}

void fsm::state2 (void)
{
        ..
        if (statehastochangetostate1)
                state = state1;
        ..
}

It is a simple fsm, but what I would like to know
are your opinions about this approach.

For starters, if you want to use a pointer to function, it would
be a pointer to member function. But IMHO, it's not a good
approach. For very simple FSMs, the C solution of nested switch
statements works well, even in C++, and I've used it numerous
times. For anything non-trivial, however, I'll use a variant of
the GoF State pattern: the FSM uses a State interface (and
abstract class) with virtual functions for each event. Plus
a derived class for each state, with a static instance of the
class. Something like:

    class State
    {
        void* operator new(size_t);
        void operator delete(void*);

    public:
        virtual State const* event1() const { return this; }
        virtual State const* event2() const { return this; }
        // ...
    };

The default implementation of each function, above, just
ignores the event. Depending on the application, you may want
to make the functions pure virtual, requiring every derived
class to override them, or treat an unexpected event as an error
condition.

Again depending on the application, you might want to pass some
data to the events, as an argument.

Finally, you derive a separate class for each state, and create
a static instance of it, somewhere where the other states can
find it. (If all of the states are defined in the same source
file, putting them in an unnamed namespace is a good solution.
Otherwise, making them protected static data members of State
works as well. And is the solution used in the GoF book, which
predates namespaces.)

A concrete event function might look something like:

    State const*
    SomeState::eventn() const
    {
        // State transition processing...
        return &nextState;
    }

--
James Kanze