Subject: Re: [boost] [msm] Review
From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2009-12-01 14:17:29
> Sure but Msm is a general-purpose library and can therefore not allow
> itself not to be performant. Quite a few Msm users are from the
> embedded world and performance does matter there (anyway, this is C++
> so it always does, right?
No, as Simon has already pointed out, for some users scalability is more
important than raw dispatch speed. For other users it's exactly the other
way round, which is why an FSM with guaranteed O(1) dispatch would surely be
a welcome addition to Boost.
>>>+ your state data is always available. In my experience, state data is
>>>not only needed in the entry or when the next event is processed, but
>>>during a transition or even at some time after a transition. This
>>>means, that you have, during a transition, access to data from the
>>>source or the target state.
>> This is simple to emulate in SC. The state data can be owned by the
>> outer state, or by the state_machine itself.
> Sure, but then the statechart documentation itself makes a pretty good
> point why this is less than
> In short, this workaround means that some data saved this way in the
> top-level fsm will only have a meaning in some of the states of this
> Doesn't this pretty much defeat the concept of state local storage itself?
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
> Granted, the limit is, for the moment, the compiler. I managed
> yesterday 150 transitions with g++4.3.
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?
-- 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk