Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2009-12-02 18:53:22

>> It doesn't, but this seems to be beside the point anyway. You wrote (in 
>> an
>> unquoted part) that Msms behavior with respect to storage in states is 
>> hard
>> to emulate with SC. Simon only showed that it isn't (unless Simon and I 
>> are
>> missing something).
>
> But (as you wrote yourself in this excellent rationale) if you have to
> move the data from state to fsm you lose part of the benefit of
> state-storage, right?

One of the points of state-local storage is that each variable used in an 
FSM has exactly the lifetime that is needed. So, a user only moves a 
variable from a state into the state_machine subclass if he finds that the 
variable's lifetime must match the one of the state_machine subclass. So he 
loses the benefit of state-local storage only because he *wants* to lose it. 
If the lifetime should be confined to only some states, then he can 
introduce a new outer state and put the variable into that. For example, in 
the StopWatch ...

<http://www.boost.org/libs/statechart/doc/tutorial.html#BasicTopicsAStopWatch>

... one of the reasons for the existence of the state Active is that it 
holds a variable.

OTOH, I admit that state-local storage is sometimes cumbersome, namely when 
state-local variables are accessed by transitions, which by default are 
always executed after source states have been exited and before destination 
states are entered. This sometimes forces you to push variables more outward 
than you want to. If the user had full control over when exactly in the 
transition sequence the transition action is called, then state-local 
storage would be more valuable (BOOST_STATECHART_RELAX_TRANSITION_CONTEXT 
does this only to some extent).

Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.