From: Darryl Green (darryl.green_at_[hidden])
Date: 2004-05-29 02:44:46
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
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
Am I missing something or doing something wrong? Can you recommend an approach
to deal with this?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk