[MSM] What's the easiest way to share data between states in a Boost.MSM state machine?
As the subject indicates, I'm trying to find the best way to share data between states in a MSM state machine. My first attempt has been to let each sub-machine and state inherit from a common base class, e.g.: struct MyStateMachine_ : public msm::front::state_machine_def<MyStateMachine_,CommonBaseClass> My idea is to add a reference to some shared data in the base class, making it easy to access the shared data from any state. The shared data reference must be passed to the base class. Questions: 1. Is it possible to pass constructor parameters to the common base class' constructor? I have tried different options without success, it seems that the default constructor with no arguments is the only option. 2. If 1. is not possible, what is the best way to initialize the shared property correctly? For example an easy method to iterate over all defined states? (not only the active ones). I have tried to iterate over all states with get_state_by_id, but this method does not enter sub-machines' states. 3. In general, what is the preferred way of implementing shared data between state classes in Boost.MSM? It would have been natural to store the data in the root state, but I can't see that there is an easy way to get access to the root FSM. (only the "nearest parent" FSM in the hierarchy is passed to the various event handler methods). Regards, Tommy
As the subject indicates, I'm trying to find the best way to share data between states in a MSM state machine.
My first attempt has been to let each sub-machine and state inherit from a common base class, e.g.:
struct MyStateMachine_ : public msm::front::state_machine_def<MyStateMachine_,CommonBaseClass>
My idea is to add a reference to some shared data in the base class, making it easy to access the shared data from any state.
The shared data reference must be passed to the base class.
Questions:
1. Is it possible to pass constructor parameters to the common base class' constructor? I have tried different options without >success, it seems that the default constructor with no arguments is the only option.
A state machine and states do need a default-constructor because of an implementation detail, which is unfortunate, but you have the possibility to create a state with your own arguments and replace the default one by yours (http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s05.html#d0e2417). Then you can call your base class constructor. You can also recurse for submachines. However I doubt you want this because if you have many states, it becomes tedious.
2. If 1. is not possible, what is the best way to initialize the shared property correctly? For example an easy method to iterate over
all defined states? (not only the active ones). I have tried to iterate over all states with get_state_by_id, but this method does not >enter sub-machines' states.
I answered a similar question some time ago on stackoverflow (http://stackoverflow.com/questions/8288713/how-to-visit-all-states-in-boost-...). This allows you to iterate over all the states and call a method they all support. Then, you have the possibility to make the submachine iterate over its states the same way in this call.
3. In general, what is the preferred way of implementing shared data between state classes in Boost.MSM? It would have been >natural to store the data in the root state, but I can't see that there is an easy way to get access to the root FSM. (only the "nearest >parent" FSM in the hierarchy is passed to the various event handler methods).
It is possible for any state to access data from any other state of the same state machine but usually the easiest is to host common data inside the state machine. All actions and guards get the "nearest" fsm as a parameter. It has already been requested a few times that MSM provides you with not only the nearest but the parent state machines up to the node. It will be done, but for the moment there is no easy way, so you will need to make your submachines "forward" data to their subsubstates upon visiting. In the previous link I have a Visit class calling resize() on all states. You can easily modify it to call say, set_data(...), then make your submachine use the same method inside set_data to forward to the subsubstates. You can also use the constructor method I pointed to in 1.
Regards,
Tommy
HTH, Christophe
Thanks for the advice! I think the option to look up parent state machines will be a very useful feature in a new version of MSM. I have tested your suggestion to iterate over a state machine's existing states. It makes it easy to iterate over all states at the top level, but as you point out, it does not dive into the child states of sub-machines. You mention that I have the possibility to "make the submachine iterate over its states the same way in this call". Does this require an active lookup to fetch a sub-machine of a given type (e.g. with the get_state<>() call), or is it possible to modify the routine to automaticallly traverse all child states that actually are sub-machines? Do you have an extended example that shows a method to traverse all substates recursively? Best regards, Tommy On Thursday, April 26, 2012 9:25:04 PM UTC+2, Christophe Henry wrote:
As the subject indicates, I'm trying to find the best way to share data between states in a MSM state machine.
My first attempt has been to let each sub-machine and state inherit from a common base class, e.g.:
struct MyStateMachine_ : public msm::front::state_machine_def<MyStateMachine_,CommonBaseClass>
My idea is to add a reference to some shared data in the base class, making it easy to access the shared data from any state.
The shared data reference must be passed to the base class.
Questions:
1. Is it possible to pass constructor parameters to the common base class' constructor? I have tried different options without >success, it seems that the default constructor with no arguments is the only option.
A state machine and states do need a default-constructor because of an implementation detail, which is unfortunate, but you have the possibility to create a state with your own arguments and replace the default one by yours ( http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s05.html#d0e2417). Then you can call your base class constructor. You can also recurse for submachines. However I doubt you want this because if you have many states, it becomes tedious.
2. If 1. is not possible, what is the best way to initialize the shared property correctly? For example an easy method to iterate over
all defined states? (not only the active ones). I have tried to iterate over all states with get_state_by_id, but this method does not >enter sub-machines' states.
I answered a similar question some time ago on stackoverflow ( http://stackoverflow.com/questions/8288713/how-to-visit-all-states-in-boost-...). This allows you to iterate over all the states and call a method they all support. Then, you have the possibility to make the submachine iterate over its states the same way in this call.
3. In general, what is the preferred way of implementing shared data between state classes in Boost.MSM? It would have been >natural to store the data in the root state, but I can't see that there is an easy way to get access to the root FSM. (only the "nearest >parent" FSM in the hierarchy is passed to the various event handler methods).
It is possible for any state to access data from any other state of the same state machine but usually the easiest is to host common data inside the state machine. All actions and guards get the "nearest" fsm as a parameter.
It has already been requested a few times that MSM provides you with not only the nearest but the parent state machines up to the node. It will be done, but for the moment there is no easy way, so you will need to make your submachines "forward" data to their subsubstates upon visiting. In the previous link I have a Visit class calling resize() on all states. You can easily modify it to call say, set_data(...), then make your submachine use the same method inside set_data to forward to the subsubstates. You can also use the constructor method I pointed to in 1.
Regards,
Tommy
HTH,
Christophe
Update: I found a template named "boost::msm::back::is_composite_state" which can be used to select a visitor type based on whether there are child states or not. With this useful metafunction, it was quite easy to make a recursive function that iterates over all states. So unless there are some major drawbacks with this method there is no need for any more specific examples. Best regards, Tommy On Thursday, April 26, 2012 9:25:04 PM UTC+2, Christophe Henry wrote:
As the subject indicates, I'm trying to find the best way to share data between states in a MSM state machine.
My first attempt has been to let each sub-machine and state inherit from a common base class, e.g.:
struct MyStateMachine_ : public msm::front::state_machine_def<MyStateMachine_,CommonBaseClass>
My idea is to add a reference to some shared data in the base class, making it easy to access the shared data from any state.
The shared data reference must be passed to the base class.
Questions:
1. Is it possible to pass constructor parameters to the common base class' constructor? I have tried different options without >success, it seems that the default constructor with no arguments is the only option.
A state machine and states do need a default-constructor because of an implementation detail, which is unfortunate, but you have the possibility to create a state with your own arguments and replace the default one by yours ( http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch03s05.html#d0e2417). Then you can call your base class constructor. You can also recurse for submachines. However I doubt you want this because if you have many states, it becomes tedious.
2. If 1. is not possible, what is the best way to initialize the shared property correctly? For example an easy method to iterate over
all defined states? (not only the active ones). I have tried to iterate over all states with get_state_by_id, but this method does not >enter sub-machines' states.
I answered a similar question some time ago on stackoverflow ( http://stackoverflow.com/questions/8288713/how-to-visit-all-states-in-boost-...). This allows you to iterate over all the states and call a method they all support. Then, you have the possibility to make the submachine iterate over its states the same way in this call.
3. In general, what is the preferred way of implementing shared data between state classes in Boost.MSM? It would have been >natural to store the data in the root state, but I can't see that there is an easy way to get access to the root FSM. (only the "nearest >parent" FSM in the hierarchy is passed to the various event handler methods).
It is possible for any state to access data from any other state of the same state machine but usually the easiest is to host common data inside the state machine. All actions and guards get the "nearest" fsm as a parameter.
It has already been requested a few times that MSM provides you with not only the nearest but the parent state machines up to the node. It will be done, but for the moment there is no easy way, so you will need to make your submachines "forward" data to their subsubstates upon visiting. In the previous link I have a Visit class calling resize() on all states. You can easily modify it to call say, set_data(...), then make your submachine use the same method inside set_data to forward to the subsubstates. You can also use the constructor method I pointed to in 1.
Regards,
Tommy
HTH,
Christophe
Update: I found a template named "boost::msm::back::is_composite_state" which can be used to select a visitor type based on whether there are child states or not. With this useful metafunction, it was quite easy to make a recursive function that iterates over all states. So unless there are some major drawbacks with this method there is no need for any more specific examples.
Best regards, Tommy
Hi, thinking about it again, I think your method not only works but also is less hassle that what I had in mind. Good idea! Christophe
participants (2)
-
B. Tommy Jensen -
Christophe Henry