[boost] Re: FSM Review

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-03-08 14:18:15

David Abrahams wrote:
> "Andreas Huber" <ahd6974-spamgroupstrap_at_[hidden]> writes:
>
>> David Abrahams wrote:
>>> "Andreas Huber" <ahd6974-spamgroupstrap_at_[hidden]> writes:
>>>
>>>> David Abrahams wrote:
>>>>> I'm not saying that Aleksey's library can handle all practical
>>>>> state machines.  I'm saying that it's possible to build a
>>>>> statically-dispatched FSM library that handles all practical state
>>>>> machines.
>>>>
>>>> In one TU or spread over multiple TUs?
>>>
>>> I was thinking of the latter.
>>
>> That depends on the functionality. I don't think it is possible if
>> you want to provide support for orthogonal regions.
>
> Sorry, I don't really understand the concept.  How are they different
> from separate state machines?

Orthogonal states are different from separate FSMs in two ways:
1. Automatic entry/exit: If a transition (or any other reaction) leads
to an exit of a state containing orthogonal regions then all the active
states inside the orthogonal regions are exited before their parent is
actually exited. The opposite happens upon entry of a state containing
orthogonal regions. With separate FSMs you'd have to manage this
yourself, which IMO becomes non-trivial with 4 or more such regions on
different levels in the state hierarchy.
2. Automatic event dispatch: An FSM lib supporting orthogonal regions
automatically searches for the orthogonal region that "is willing" to
react to the current event. Again, with separate FSMs you'd have to do
that yourself (dispatch to first FSM and if that didn't consume the
event, dispatch to second FSM and so on). This is trivial to do manually
but IMO tedious.

Regards,

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