Re: [boost] Proposal to add a Boost.FSM library

From: Andrey Semashev (andysem_at_[hidden])
Date: 2006-12-17 11:34:42

"Andrey Semashev" <andysem_at_[hidden]> wrote in message 
news:12010137442.20061217134912_at_mail.ru...
> Hello Pavel,
>
> Sunday, December 17, 2006, 7:44:41 AM, you wrote:
>
>> "Andrey Semashev" wrote:
>
>>> I would like to purpose a new library addition to Boost: Boost.FSM.
>>> FSM stands for Finite State Machine, so the library is aimed to ease
>>> creation and support of state machines in C++.
>
>> Are you aware of Boost.Statechart?
>> (will be released in 1.34, available from CVS now)
>
>> It was originally called Boost.FSM.
>
> No, not really. I'll take a look at it.

Well, I have read the Boost.Statechart documentation. Its functionality 
covers and extends my proposed implementation, though I must note its 
several deficiences:
- The author notes the performance issue of Boost.Statechart. I have not 
inspected the library implementation but as I can see from the 
documentation, the performance of transition between states and event 
delivery to a reaction handler linearly depends on the number of reactions 
in the state. Additionally, a transition between states involves memory 
allocations which, besides the performance losses in the first place, leads 
to memory fragmentation. A custom pooling allocator partially addresses the 
problem but in most real-world applications it will not evade the necessity 
of pool synchronization costs. In the proposed implementation no allocations 
take place neither on transitions nor on event delivery. In addition, none 
of these operations depend on state, transitions or reactions number. The 
implementation even tries to minimize virtual function usage. So, even 
though I haven't done experimental comparisons, IMO the proposed 
implementation will outperform Boost.Statechart.
- In Boost.Statechart to declare a custom reaction on some event we must add 
it as an element to the "reactions" typedef besides defining a "react" 
member function. No such duplication is needed in the proposed 
implementation - only "on_process" (the synonym for "react") handler is 
needed. As a nice side effect it is possible to rely on C++ overload 
resolution rules and even declare "on_process" templates. That makes the 
state code cleaner and more natural, IMO.
- I can see no way to return a value from a Boost.Statechart's machine 
except by passing a reference or a pointer in the event. There is such 
functionality in the proposed implementation.
- I can see no easy way to describe a transition that should take place 
regardless of the current state of the machine in Boost.Statechart. To do 
this one must put the transition into each state's "reactions" type 
sequence. There is a much simplier way to do this in the proposed 
implementation.
- Common state data in Boost.Statechart can be accessed via "context"s 
mechanism. Although this is a very nice solution, there is no need in such 
in the proposed addition. In most cases common data can be accessed just 
like it is another member of the state class. In rare cases a C++ scope 
qualification should be added.
- Maybe some other minor things that may come up after a real-world 
evaluation of Boost.Statechart.

To be honest, there is quite an amount of functionality of Boost.Statechart, 
that is not covered by the proposed Boost.FSM. Here is a brief list:
- No UML support. Actually, in my practice a have never had a real need in 
one. Maybe that's just a lack of my experience.
- No nested states support. The proposed Boost.FSM supports only flat 
machines.
- No orthogonal states support, though in many cases they can be easilly 
replaced with additional state machines nested in a state.
- No history support. This feature can be easilly implemented by user in the 
proposed Boost.FSM. A user may store state identifiers into a container that 
is accessible from any state.
- Less support for modularity. Although it is possible to separate states of 
the proposed Boost.FSM state machine into several translation units, the 
complete state machine will still need all states to be defined, not just 
declared.
- No support for posting events and asynchronous state machines. Though 
these features may be implemented as an outer layer to a regular state 
machine.

That being said, I may only purpose my implementation as a lightweight 
addition to the Boost.Statechart aimed to solve performance and simplicity 
issues for small and light FSMs. Is there any need in such?