Re: [boost] Proposal to add a Boost.FSM library

From: Andrey Semashev (andysem_at_[hidden])
Date: 2006-12-22 12:58:05

Hello Andreas,

Friday, December 22, 2006, 6:52:03 PM, you wrote:

> Hi Andrey

[snip the performance discussion]

>> 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.

> As soon as an FSM needs to be able to process events of arbitrary types
> you usually need to allocate these events on the free store anyway, also
> allocating the states there just doubles the runtime needed for 
> new/delete. Sure, you can save all those free store allocations when 
> your FSMs only need to deal with one type of event and state but for 
> many applications this simply is not flexible enough.

I can't quite agree with you. As it comes from my experience, one of
the most frequent FSM use cases is when the state machine implements
some public interface. In this case interface method calls have to be
translated into events that may be accepted by FSM. And most likely
these events will be on the stack.

As for states' allocation and deallocation, there may be other issues
with it, besides of performance loss. I'm not quite sure you have read
our discussion with Alexander Nasonov in this thread, where I pointed
out that the fact that the state is deleted when being left may be
inconvenient if the state has its local data. If the state is visited
again all these data are lost. And moving these data to an outer state
or even the to the state machine class makes it exposed to other
states that shouldn't have had access to it. Additionally as the data
amount and states number raises the code of these data-holding classes
gets more messy.

[snip]

>> - 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.

> Correct. How do you return a value? With boost::any?

Not necessarily. The return type is passed in a state machine's
template parameter and may be any type, including boost::any. This
feature is optional, so by default this type is "void" (IOW, the FSM
returns nothing).

>> - 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 are two ways:
> 1. Define an outermost state that contains all other states and add a 
> reaction triggered by event_base.
> 2. Add a member-function unconsumed_event to the state_machine<> 
> subclass:
> <http://www.boost-consulting.com/boost/libs/statechart/doc/reference.html#unconsumed_event>

I see. Actually, the first way is what I was looking for. The second
one allows a quite different thing, as I see it: to make a default
reaction on any unexpected (not specific and maybe expected) event in
any state.

BTW, is there any way to make Boost.Statechart's machine not compiling
if it doesn't expect some particular event type? IOW, to force the
machine to support all event types being passed to it?

There is a way to do so in Boost.FSM, though this feature is not
pointed out in the documentation. I'll update it before formal review
request.

>> 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?

> I don't have time to look at your proposal right now, but I would guess
> that there is a need in a simple FSM lib that does not have all the 
> bells and whistles of Boost.Statechart but does provide top-notch 
> performance in return. However, I don't see how it can be a part of 
> Boost.Statechart, it should probably be a separate library.

Agreed, I too see it as a separate lib that complements Statechart.

-- 
Best regards,
 Andrey                            mailto:andysem_at_[hidden]
PS: Thank you for such a detailed answer. I have almost began thinking
that there's too little interest in this library.