Re: [boost] [msm] Review
Hi Andreas,
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? OTOH you get the advantage of automatic destruction. Even better would be to allow both possibilities through a policy. For every design decision taken in Msm, you will probably find a case where SC will offer a better solution in some cases and vice versa. At first glance, it seems that state storage is the same in both libraries, but as it turns out, there are subtle differences.
That's good to hear. BTW, is there only a limit on the number of transitions, or is the number of states limited in some way to? Does the number or orthogonal regions have an influence?
I never managed to break a compiler purely on the number of states (I tried up to 80). The orthogonal regions have very little influence as their metaprogramming needs are very small. Regards, Christophe
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.
participants (2)
-
Andreas Huber -
Christophe Henry