Re: [boost] FSM Review Announcement

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-05 23:02:57

David Abrahams wrote:
> on Tue Aug 05 2008, Chris Knight <cknite-AT-gmail.com> wrote:
> 
>> Andrey Semashev wrote:
>>> Jurko Gospodnetić wrote:
>>>>   What are the intended and actual differences from the already accepted
>>>> Statechart library?
>>> The main differences are simplicity and performance. The performance
>>> tests show difference by an order of magnitude, in the best case for
>>> Boost.Statechart. The overall design of Boost.FSM is geared more to
>>> compile-time code generation, while Boost.Statechart aims to support
>>> more scaled machines and therefore is geared towards run-time. There is
>>> a section in the docs that compares the libraries.
>> I can attest to the necessity of this. We have several exchange libraries that
>> require state machines to implement their data protocols but we use a 
>> home-brewed boost::mpl::inherit_linearly implementation because the 
>> features of Boost.StateChart simply brings in to many performance penalties
>> for our simpler usage that would fit within the Boost.FSM framework. In fact,
>> if I remember correctly, we used a thing on Boost.Vault called "FSM" as an 
>> implementation guide.
> 
> I don't know if you've seen the FSM examples from "C++ Template
> Metaprogramming" or not.  It would be interesting for this library's
> documentation to explain its advantages over that approach (I can see
> some from here already).

No, I don't have that book.

> One other thing I'd like to see is an implementation of nested states.
> I once promised some people who needed that functionality that I'd
> extend our framework to support them, but was never able to figure out
> what their semantics are ;-)

I thought about nested states, but, the way I understand it, there are 
no advantages of nested states over nested state machines. Obviously, 
you can define as much FSMs as you like and nest them within states as 
you need.