Statechart serialization

[mbrodeur65]

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

[Andreas Huber-3]

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.

_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Lukasz]

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.

[Andreas Huber-3]

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.


_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users