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