Re: [boost] [review] FSM Second Call for Reviews

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-30 13:27:15

Thomas Klimpel wrote:
> Andrey Semashev wrote:
>>> The most important design decision seems to be let the state machine 
>>> have a member of a class that derives from all states in StateList.
>>> The switching between the states now changes which of these
>>> "base classes" is "in charge" of handling events.
>>>
>>> I see two reasons for this design choice. The first is performance,
>>> which is one of the main goals of the library, the second is that the
>>> library models a "state machine" instead of a "finite state machine".
>> Why? The machine is definitely finite, since it consists of finite
>> number of states and defines finite number of transitions between them.
> 
> Other designs model 'states' as enums, while the fsm library models 'states' as classes. A 'state' modeled by an enum would be a "stateless state", while a 'state' modeled by a class can have "internal state". I'm quite sure that the "finite" in "finite state machine" refers to the number of "stateless states", because the Wikipedia article says: "A finite state machine is an abstract model of a machine with a primitive internal memory.". In other words, the resulting "machine" (created by "fsm::state_machine<...> machine") viewed as a black box is not guaranteed to only have a finite number of "stateless states", so it may exhibit behavior that is not possible for a finite state machine (like parsing a grammar that is too complex for a finite state machine)

Ok then. I didn't think of the internal data of the states as an
additional sub-state.

>>> The modeling of the "transition" concept could and should probably be improved.
>>> The transition table where I can specify for given "intial states" and "events"
>>> the resulting "final states" and "actions" (modeled as functions that take a const
>>> reference to the corresponding event) to perform appears superior to me.
>> You already can do that, as I've shown in my replies to David. The only
>> difference with TMP approach is that there's no need to specify actions
>> in the transition table. Is this what bothers you?
> 
> What bothers me is that although the important design decisions of the fsm library seem to be OK, it doesn't seem to please its potentials users.
> 
> But let's focus on this particular 'design flaw'. As I understand it, it's not true "that there's no need to specify actions". The actions need to be specified, not as entries in the transition table, but by overriding the "transit" method of the "fsm::transition<InitialState, Event, FinalState>" class. So I get the impression that I will have to create a new class for every transition, because this class will have to derive from the corresponding "fsm::transition<InitialState, Event, FinalState>" class, in order to be able to override the "transit" method. This seems to make to resulting code much more verbose (and difficult to read) than the resulting code for the TMP approach.

Not exactly. You don't have to override the transit handler unless you
want to define some non-trivial transition logic. If you stick to the
same degree of functionality that TMP provides (IOW, no runtime
conditions for the transition to take place), then you can use the
fsm::transition class as a direct replacement for the row template in
the TMP approach.

If you have to decide when and which state to transit to in runtime,
then yes, you have to define your custom transition rule.