Re: Design for deriving one state-machine / double-dispatch class from another

On 6 Apr., 22:03, Dave Abrahams <d...@boostpro.com> wrote:


Sorry for the delay, Easter time...
The documentation is not talking about this subject because it has
never been requested, but MSM does allow quite a bit.
As a reminder, MSM is based on a transition table. States are
independent classes and are only logically part of a fsm if referenced
in the table. To try to draw it as UML, it would be States <-- fsm,
with <-- being a dependency.
For ex, see http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s02.html#d0e334.

The only 2 things a state machine needs is an initial_state and a
transition_table typedefs.

The easiest way, which most people do, is to inherit a front-end state
machine class and provide a new table and initial state. States being
not part of the fsm, rewriting the table is sufficient and only means
a few lines of copying.

The second way, provided as example inside libs\msm\doc\HTML\examples
is in the directory distributed_table. In this case, the table is
distributed in the different states, and the fsm itself has none. A
state then looks like:
struct Empty : public msm::front::state<>
{
    template <class Event,class FSM>
    void on_entry(Event const&,FSM& ) {std::cout << "entering: Empty"
<< std::endl;}
    template <class Event,class FSM>
    void on_exit(Event const&,FSM& ) {std::cout << "leaving: Empty" <<
std::endl;}
    void open_drawer(open_close const&);

    struct internal_transition_table : mpl::vector<
        // Start Event Next
Action Guard
        //+-------------+---------+-------------+---------
+---------------------------+----------------------+
    msm::front::a_row2 < Empty , open_close , Open ,
Empty,&Empty::open_drawer >
    //+-------------+---------+-------------+---------
+---------------------------+----------------------+
    > {};
};

See here the distributed table. The drawback of this method is that it
forces strong coupling between states (like in your example) as they
need to know each other. MSM can do it, but it goes against its
philosophy of reuse and I think very few have really been interested
in this capability. But it allows a very good reuse while inheriting.

The third way requires a bit of metaprogramming: inherit a fsm, and
add/delete/change the transitions you need. Adding is easy, the other
2 harder. If we take as basis the example provided in the functor
front-end (http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/
examples/SimpleWithFunctors.cpp), let's say we want to add a
transition Stopped => Playing on an event called new_event. We can use
boost::mpl::push_back:

// inherit from player_ fsm
struct derived_player : public player_
{
  // new transition Stopped => Playing with event new_event
  typedef Row<Stopped, new_event, Playing> added_row;
  // new transition table based on player_ with an added transition
  typedef
boost::mpl::push_back<player_::transition_table,added_row>::type
            transition_table;
};

HTH,
Christophe

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]