Re: [boost] [msm] Nested submachines and explicit state entry

Subject: Re: [boost] [msm] Nested submachines and explicit state entry
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2010-06-09 05:44:36

<snip>
>I have made an example which implements the UML state chart provided by Michael.
>
>well it does not compiles with VC9 :(.
>
>it compiles as fare as the explicit entry target state is a simple
>state but does not if it is a composite sate (e.g.: a sub state
>machine).

There are several reasons to this and it took me a while to figure out
what was happening.
The first one is that there are 2 errors in the example:
RunningStateMachine::Inner1::direct<RunningStateMachine_::Inner1_> should be:
RunningStateMachine::direct<RunningStateMachine_::Inner1>

As you are directly entering RunningStateMachine, not Inner1.

The second has to do with the fact that msm looks for states in the
transition table. In particular, RunningStateMachine has:
      struct transition_table : mpl::vector<
        //    Start     Event         Next      Action				Guard
        //    +---------+-------------+---------+---------------------+----------------------+
        a_row < InitialState   , event4    , InitialState   ,
&RunningStateMachine_::onEvent4 >
        //    +---------+-------------+---------+---------------------+----------------------+
      > {};

There is no Inner1 or Inner2 to be found, so you need to tell msm
about them. Add in RunningStateMachine:
typedef mpl::vector<Inner1,Inner2> explicit_creation;

So now it should compile. But it doesn't because I think VC9 has a bug
and seems to look for Inner1 not in RunningStateMachine 's table but
in Inner1's, then complains not to find it.
MinGW g++4.4 compiles the code fast and correctly.

However, VC9 is not the only one with bugs, and if you add Inner1 into
RunningStateMachine's table, it will not compile, so msm also has a
bug and I simply forgot the case of a submachine being an explicit
entry. You just happen not to notice it in this example.
I attach you the corrected example in case you use g++ and do not need
Inner1 in RunningStateMachine's transition table.

So, we'll have to live with this restriction for the moment and I
offer you an alternative solution. Replace the explicit entry by an
entry point (from a design perspective, I find it better anyway).
I attach you this solution too.

HTH,

Christophe