Re: [boost] [msm] Review

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.

[snip]
>>>+ 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
> ideal(http://www.boost.org/doc/libs/1_40_0/libs/statechart/doc/faq.html#StateLocalStorage).
> 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
> fsm.
> 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 
missing something).

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

Regards,

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