From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-06 10:28:22
Kowalke Oliver (QD IT PA SI) wrote:
> Hello,
>
>>> Hi Martin.
>>>
>>>> The formal review for Andrey Semashev's Finite State
>> Machines (FSM)
>>>> library is scheduled for August 11th to 20th.
>>> 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.
>
> Is it correct that Boost.FSM can not defer an events (I didn't found a statement in the docs)?
Yes, this feature is not supported.
> That means in yout tutorial the state Processing consumes the event passed to template< typename T > void on_process(T const&)?
Right.
> If so - how Boost.FSM supports you if the order of passed events are not predictable?
The library itself does not mandate the order of events and I am
convinced that this is the right thing. The events are passed to the
machine implementation (i.e. states and transitions) in the order they
are received. It is up to the implementation to support (or not support)
a particular order of the events.
The solutions for event deferring may be very different and involve
other libraries (such as Boost.Thread, for example), depending on the
desired effects. In fact, it is a new library of event dispatching that
you want. I consider it out of the Boost.FSM scope.
PS: I was thinking about implementing such a library as a separate
submission, but I'm too short in time.