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

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-30 03:12:34

Thomas Klimpel wrote:
>> What is your evaluation of the design?
> 
> When I look at finite state machine in Wikipedia, Fig. 1 shows me an "Example  of a Finite State Machine". The blue words "state", "transition", "transition condition", "entry action" in this picture probably represent some of the important notions in this domain. How does the FSM library relate to these concepts?
> 
> I haven't investigated how the different types of "actions" are modeled by the library, or whether they are modeled at all.

They are. The article defines the following actions:
- Entry action. Is modeled with on_enter_state handlers.
- Exit action. Is modeled with on_leave_state handlers.
- Input action. Is modeled with on_process handlers.
- Transition action. Is modeled with transit handlers.

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

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

> The modeling of the events as arbitrary classes makes sense to me. I haven't investigated in detail the amount of support functionality related to the event concept. A predefined event class template that takes enums as template parameter, or some way to restrict (at compile time) the possible events handled by a state machine come to my mind. However, these are probably just minor details.

You can use any type as events, including fundamental types. There is
support for automatic event generation, in which case you can tag events
with intergal/enum or a type.

> So in conclusion, most important design decisions are probably OK, but the design as a whole is not finished and polished enough.

Could you, please, elaborate which particular design flaws you are
referring to?

>> What is your evaluation of the implementation?
> 
> I did take a look at the implementation and tried to understand it. It may be OK, but it uses tools that I'm not sufficiently familiar with.

It's true that the implementation could be simplified. It initially was
quite simple, without Boost.Preprocessor usage. However, I moved to the
current implementation to improve compile times and reduce the resulting
binary size.