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@mail.ru PS: Thank you for such a detailed answer. I have almost began thinking that there's too little interest in this library.