Hi, I'm looking for a solution to serialize boost::statechart objects. I'm aware that this feature is on the statechart library todo list but was wondering if there are any workaround to achieve this with the latest boost release (1.34) ? thanks for your help ! mbrodeur65 -- View this message in context: http://www.nabble.com/Statechart-serialization-tf4131326.html#a11749139 Sent from the Boost - Users mailing list archive at Nabble.com.
Hi mbrodeur65 <martin.brodeur <at> adacelcanada.com> writes:
I'm looking for a solution to serialize boost::statechart objects. I'm aware that this feature is on the statechart library todo list but was wondering if there are any workaround to achieve this with the latest boost release (1.34) ?
For non-orthogonal machines, saving the state is relatively easily done by inspecting the current state configuration with the public interface (state_machine<>.state_begin() & state_machine<>.state_end()). Loading is more cumbersome as you need to be able to go to the previously stored state after initiation. The only way to do this at the moment is to introduce special transitions. Not really pretty and a lot of grunt work, I know, but that's the current state of affairs regarding serialization. IIRC, the serialization library still does not offer a way to serialize objects that have an overloaded operator new. This however would be an inevitable prerequisite for a decent statechart serialization implementation. HTH, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Hello, I'm not sure i understand how this would work. If i use the serialization library, then i could serialize the current state (by inspecting the current state configuration as you said). But what would happen to all the members of the parent class (for example "simple_state" ) since they don't support serialization ? Unless you meant to use some other serialization method ? As for the "special transitions", i suppose i would need a sort of "initial transition" per state that would allow me to go to it directly, right ? Also, if i have (and i sure will) state local storage, then i would need some way to restore its values, which i don't quite see how it would work using this approach (since i'm not re-creating the object using the one that was restored but rather using the transition). Thanks, Lukasz K. Andreas Huber-3 wrote:
For non-orthogonal machines, saving the state is relatively easily done by inspecting the current state configuration with the public interface (state_machine<>.state_begin() & state_machine<>.state_end()). Loading is more cumbersome as you need to be able to go to the previously stored state after initiation. The only way to do this at the moment is to introduce special transitions.
-- View this message in context: http://www.nabble.com/Statechart-serialization-tf4131326.html#a12058696 Sent from the Boost - Users mailing list archive at Nabble.com.
Hi Lukasz
I'm not sure i understand how this would work. If i use the serialization library, then i could serialize the current state (by inspecting the current state configuration as you said). But what would happen to all the members of the parent class (for example "simple_state" ) since they don't support serialization ? Unless you meant to use some other serialization method ?
As long as you save all the custom members of the current innermost state and all its outer states *and* also save the class name of the current innermost state you have made persistent all information that is necessary to reconstitute exactly the same state during loading, see below.
As for the "special transitions", i suppose i would need a sort of "initial transition" per state that would allow me to go to it directly, right ?
Exactly.
Also, if i have (and i sure will) state local storage, then i would need some way to restore its values, which i don't quite see how it would work using this approach (since i'm not re-creating the object using the one that was restored but rather using the transition).
You'd first transit to the state (probably with a huge switch-case that takes a different transition based on the previously saved name) and then assign the saved values to the state-local members. You'd have a different load function for each innermost state. A lot of grunt work, but it's possible as long as your machine is non-orthogonal. Unfortunately, there's no way to do the same for machines with orthogonal regions. HTH, Andreas
Andreas Huber-3 wrote:
For non-orthogonal machines, saving the state is relatively easily done by inspecting the current state configuration with the public interface (state_machine<>.state_begin() & state_machine<>.state_end()). Loading is more cumbersome as you need to be able to go to the previously stored state after initiation. The only way to do this at the moment is to introduce special transitions.
-- View this message in context: http://www.nabble.com/Statechart-serialization-tf4131326.html#a12058696 Sent from the Boost - Users mailing list archive at Nabble.com.
-- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Hi Seeing that the serialization library, since 1.39, supports serialization of objects that have an overloaded operator new, what is the current state regarding serialization? Reason for asking is that we have a large and complex state machine which we consider implementing using a new state machine library supporting orthogonal states. Utilizing orthogonal states can reduce complexity in the legacy state machine. We already have some experience with boost::statechart and really like how code can be organized and spread over multiple translation units making it maintainable. But we also require the state machine to be restored from persistent storage and without some sort of serialization i see no way to restore a state machine utilizing orthogonal states. Regards Svein-Eirik Flasnes -- View this message in context: http://boost.2283326.n4.nabble.com/Statechart-serialization-tp2569951p467266... Sent from the Boost - Users mailing list archive at Nabble.com.
participants (4)
-
Andreas Huber -
Lukasz -
mbrodeur65 -
Svein-Eirik