Re: [Boost-users] Accessing MSM attribute under specific conditions causes non-compile
Thank you for your help!
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? What is fsm equal to when an entry action is performed?
Here's some code that shows exactly what can be set where and when for
anyone else who is trying to figure this out...
#include <vector>
#include <iostream>
#include
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
Hi again. I understand what you are saying and I guess the real problem comes down to my (mis)understanding. The fsm object, as written, isn't a state machine -- rather it's a composite state. The fsm object itself represents the outer shell state, and the states inside the fsm represent the submachine. This is very clear when using a fsm as a sub-state-machine, but not so clear from the top level. Now that I better understand what's going on, I can see that you implmentation is indeed fully correct, it's just confusing to me because of nomenclature. I guess if there were any change, it would be to rename fsm's to "composite_states", and then write in the documentation that the top-level FSM is always composed of a single composite_state which you call directly, as the only difference between a composite state and an fsm is that an fsm would not normally have an entry and exit action. This is even more clear when I note that having an entry action on both the FSM and the initial state "seems redundant." And it is, but only for the top-most level composite state. For composite state embedded in other machines, history could cause the entry action on the composite state to be called, but the not the entry action on the (normally) initial state. As it seems too late for a change of that magnitude, I'll just have to content myself with a better understanding of what's going on... Thanks for taking your time to help. -Chiem
This is even more clear when I note that having an entry action on both the FSM and the initial state "seems redundant." And it is, but only for the top-most level composite state. For composite state embedded in other machines, history could cause the entry action on the composite state to be called, but the not the entry action on the (normally) initial state.
I don't think it's redundant if you consider the case of orthogonal regions. In this case, you usually want an entry action called only once. In any case, I think I have to precise the doc a bit on this. Regards, Christophe
participants (2)
-
Chiem Whua Ma -
Christophe Henry