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

<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

On 9 June 2010 11:44, Christophe Henry <christophe.j.henry@googlemail.com> 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
participants (2)
-
Christophe Henry
-
Richard Szabo