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

Subject: [boost] [msm] Nested submachines and explicit state entry
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2010-06-08 06:58:01

Hi Michael,

>As already stated in the documentation it is possible to have explicit
>state entry into another submachine within a state machine.
>
>Is there a possibility to have a state machine, which has another
>submachine with explicit state entry and that submachine has another
>submachine with an initial transition.
>I put that together in a picture and attached it. I hope then it gets
>clearer what I want to do.
>The picture shows just a simplified version of the overall state machine
>and I discarded some other states, transitions and orthogonal regions.

Starts becoming an interesting case ;-)
Yes it should work. I tested with the same depth-level without any
problem. What is not supported yet would be if your explicit entry was
going into a substate of a submachine of a submachine, meaning you can
only "cross" one submachine boundary. So your example is ok.

>How do I have to declare the transition table and states in that case?

A transition table is always declared inside a state machine, after
the states have been declared. In my examples I always declare states
inside the front-end but it is only for readability. In your case, you
could declare the SM1 front-end, then inside its declaration add the
one for RunningStateMachine, then inside RunningStateMachine the one
for Inner1 and Inner2. After Inner1 and Inner2, the table for
RunningStateMachine, then the table for SM1. something like:

struct SM1_...
{
   struct RunningStateMachine_...
   {
       struct Inner1_...;
       typedef msm::back::state_machine<Inner1_> Inner1;
       ...
       // add RunningStateMachine table
   };
   typedef msm::back::state_machine<RunningStateMachine_> RunningStateMachine;
   // add SM1 table
};
typedef msm::back::state_machine<SM1_> SM1;

>Are there any restrictions regarding nested depth?

Not in the library. I see just 2:
- your patience while compiling
- your compiler. At some point, it will probably get pissed off ;-)

Regards,
Christophe