Hi,
I see now that it's not that that the sub-machine is a state of the main machine, but ANY time you have an entry action performed
directly from the machine level the fsm is reported as a state and not as an fsm.
This isn't a problem since I know this is happening, but perhaps it might be possible to change this so fsm entry actions put the fsm
in the fsm parameter slot?
I don't think it'd be a good idea. Or I might misunderstand your point.
What is fsm equal to when an entry action is performed?
FSM is the state machine containing this state / state machine / terminate state etc. STATE is the state being entered / exited. This means, if you have a state executing this entry, you can rely on it being in the STATE parameter. If later you replace this state by a submachine (which is also a state, right? ), your "state" is still represented by the STATE parameter. Anything else could be rightfully considered a violation of the liskov substitution principle. Imagine if you had to rewrite all your functors because you move from a state to a submachine... I'm afraid you're confusing a type, like state_machine with its function in the context of an outer state machine. You're not seeing a TERMINATE_STATE template parameter, right?
Here's some code that shows exactly what can be set where and when for anyone else who is trying to figure this out...
Let's typeid the parameters: rootFSM_action: When this executes, the current state is MSM_B, there is no containing FSM => STATE is MSM_B. FSM also because we have no outer fsm, but this a corner case. I wouldn't want to pass a dummy fsm. someAction: When this executes, the current state is MSM_A, containing FSM is MSM_B => STATE is MSM_A, FSM is MSM_B because this substate is contained by MSM_B. I fail to see what confuses you. FSM is the containing fsm, STATE is the state executing an entry/exit. Losing the information of which fsm is your outer fsm only because the state happens to be a submachine would surely make a lot of people unhappy. HTH, Christophe