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

Subject: Re: [boost] [msm] Nested submachines and explicit state entry
From: Richard Szabo (sz.richard_at_[hidden])
Date: 2010-06-09 06:52:56

On 9 June 2010 11:44, Christophe Henry
<christophe.j.henry_at_[hidden]> wrote:
> <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.

actually I have made 2 mistakes :). One above the second is that I used Inner1_
which is a frontend instead of Inner1 caused that the on initial transition
is getting triggered after entry of Inner1

I found it even strange that it compiles when the frontend of and
inner state machine is used in the outer state machine transition
table.

>
> 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.

Well in our environment we actually using both VC9 and g++ because our
SW is spitted in to several parts some part is running on windows some
are running on embedded HW.

>
> 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.

Thanks for the solution we come to the same conclusion as well.

>
> HTH,
>
> Christophe
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>