Re: [prereview request][fsm]
Andreas, I have looked more thoroughly at the fsm library and have this specific problem I would like advice on. The source state (as well as all the rest of the active direct and indirect inner states of the innermost common outer state) is destructed before the transition action runs. This means the actin doesn't have access to any of this context, considerably reducing the utility of state local storage. The stopwatch example shows the storage being used in the exit action, which is fine. A more complex example would be likely to have separate actions for multiple transitions. It seems that if actions need access to the state local storage of a state being left one must do the following: 1) Have states with only one transtion. 2) Be prepared to execute the actual "work" done by the system (the actions) in the exit action (which is a destructor). I don't find either of these attractive. Alternatively, a custom reaction can be used. The react function can do processing in the context of the source state (it is a member of the source state). I'm not sure how easy it is to access other active (inner or outer) states at this point? So I end up with a "pre exit" action. User defined exception handling can be used here (that is, it is possible to: 1) map an exception to an event 2) make (or not) an immediate transtion to an arbitrary state based on an exception 3) terminate 4) let the fsm framework deal with it This seems reasnably ok, but doesn't make for a nice transition table representation (the transition information is "hidden" in the react() function). Another option is: Keep a shared_ptr<my_local_storage> in the state. Construct a my_local_storage in the state constructor. In the react member function, take a copy of teh shared_ptr. This should keep my storage "alive" until the transition is complete and the new state has been entered (actually a bit longer than I would like). Am I missing something or doing something wrong? Can you recommend an approach to deal with this? Thanks Darryl Green.
Darryl Green wrote:
Andreas,
I have looked more thoroughly at the fsm library and have this specific problem I would like advice on.
The source state (as well as all the rest of the active direct and indirect inner states of the innermost common outer state) is destructed before the transition action runs. This means the actin doesn't have access to any of this context, considerably reducing the utility of state local storage. The stopwatch example shows the storage being used in the exit action, which is fine. A more complex example would be likely to have separate actions for multiple transitions. It seems that if actions need access to the state local storage of a state being left one must do the following: 1) Have states with only one transtion. 2) Be prepared to execute the actual "work" done by the system (the actions) in the exit action (which is a destructor).
I don't find either of these attractive.
Alternatively, a custom reaction can be used. The react function can do processing in the context of the source state (it is a member of the source state). I'm not sure how easy it is to access other active (inner or outer) states at this point?
Hmmm, it is difficult to diagnose your problem without seeing any code or state charts, so I can only guess here. It seems very unlikely that you could have missed it but did you miss simple_state::context<>()? It seems that this should pretty much solve all your problems? I assume that you want to access the same variable from entry actions, exit actions and transition actions. If this is the case then you need to put the variable in question in an outer context that is shared by all the states from whose entry or exit actions you want to access it. Moreover, you also need to ensure that this outer context always exists when any of the transitions are made, i.e. you may need to push the variable further outward. The state_machine<> subclass itself acts as the outermost context. Transitions may take place in this context, i.e. *all* states have been left before the transition action is executed. If so, the variable needs to be made a member of the state_machine<> subclass. You can then access the variable from entry and exit actions with the context function template. From transition actions you can access the variable either directly or also through the context function template. Pitfall: Whenever you need to call context<> from an entry action, you must derive the associated state from state<> instead of simple_state<>. HTH, Andreas
participants (2)
-
Andreas Huber -
Darryl Green