Boost logo

Boost :

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

"Andrey Semashev" <andysem_at_[hidden]> wrote in message
> 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
- 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
- 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
- No support for posting events and asynchronous state machines. Though
these features may be implemented as an outer layer to a regular state

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?

Boost list run by bdawes at, gregod at, cpdaniel at, john at