Boost logo

Boost :

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 ...


... 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
does this only to some extent).


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at