Re: [Boost-users] Accessing MSM attribute under specific conditions causes non-compile

Subject: Re: [Boost-users] Accessing MSM attribute under specific conditions causes non-compile
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2012-09-05 15:39:35

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