Re: [boost] [fsm review] Comparison with ad-hoc FSM coding

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-20 00:04:18

David Abrahams wrote:
> on Tue Aug 19 2008, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
> 
>> and, in fact, is more limiting, because it doesn't allow to specify
>> rules that apply to a subset of states and events. A small example
>> from the docs.
>>
>> // Let's define the fsm::transition's analogue that triggers
>> // not only when the event type is equal to the specified,
>> // but even when it is derived from it.
>> template<
>>   typename CurrentStateT,
>>   typename EventT,
>>   typename TargetStateT
>> struct same_or_derived_event_transition :
>>   public fsm::basic_transition< TargetStateT >
>> {
>>   // We only need to specify the static predicate
>>   // that selects the transition
>>   template< typename StateT, typename EvtT >
>>   struct is_applicable :
>>     public mpl::and_<
>>       // We should check that state type is correct
>>       mpl::or_<
>>         is_same< CurrentStateT, fsm::any_state >,
>>         is_same< CurrentStateT, StateT >
>>       >,
> 
> Isn't the above "or" clause always true, and if not, why not?

No, it's not. The FSM instantiates is_applicable on every state and
every event type. The above condition yields true only for the selected
state (CurrentStateT), unless CurrentStateT is any_state. If it is, then
yes, the above "or" is true for all states.

>>       // Now we shall check the event type
>>       mpl::or_<
>>         is_same< EventT, EvtT >,
>>         is_base_and_derived< EventT, EvtT >
>>       >
>>     >
>>   {
>>   };
>> };
>>
>>>> In fact, I find your syntax more verbose for the unneeded fourth
>>>> column of the table.
>>> It's only unneeded if you think it doesn't convey information that's
>>> important to understanding the FSM.  From my POV, it does.  That's why
>>> arcs in an FSM diagram are often labeled with their associated
>>> transition actions.  How does a user of your library associate actions
>>> with transitions if they don't go in the table?
>> The action is totally defined by the event and the current state.
> 
> I don't see how that answers my question.
> 
>> Handler names are always the same and thus need not to be present in the
>> table.
> 
> Do you mean to say that every transition action is named the same and
> the one to execute is chosen by overload resolution?

Yes. Every transition rule (or a row in STT) has one or more "transit"
member functions that accept references to the current state and the
event being processed. So, when a particular transition rule is chosen,
the library simply calls the "transit" member in that particular rule.