"Andrey Semashev" <andysem@mail.ru> wrote in message news:12010137442.20061217134912@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?