"Commander Pirx"
thanks for the help. I compiled the project with GCC. The behaviour is unchanged. Furthermore I'm not able to reproduce the behaviour in a simplified demo code. I've even tried to debug the statechart library and read the http://www.boost.org/doc/libs/1_40_0/libs/statechart/doc/reference.html#proc... documentation carefully. But I must honestly say, I have not quite understood. Thats why I have a simple question: Is it guaranteed that the innermost states are called first?
It depends :-). Seriously, e.g. in your demo program, there's *no* guarantee that the reaction in state X is called first. Whether it is or it isn't depends on which innermost states is checked first for a suitable reaction. If X is checked first, then you get the behavior of your demo program. If either Y or Z is checked first then you get the behavior you observe in your application. Exactly which innermost state is checked first is *arbitrary*. More importantly, if the first checked innermost state does not define a reaction for the event, then its direct *outer* state is checked next (state A in your example prog). Hope this clears things up, if not please let me know.
Note: When working with the statechart libraries I got some ideas to improve the "usability". Think about it as a wishlist.
1. Debugging features, like in the Spirit Library. e.g. easy naming of states, tracing the event route, more debug output (verbose mode)
I'll see what I can do, however in any case this will definitely not make it into the next release, as other stuff is already pending.
2. Calling the state constructor with an event. something like transit<S>( event );
You already can pass the event to the transit function, but the event is never passed to any state constructor (only to the transition action). This is a very popular request, but I'm afraid this will not be possible. The problem is that the state constructor can be called as a result of a number of different events. However, I plan to support a work-around (triggering_event, see to-do list) for the next release.
3. A process_event() method that acceepts an intrusive pointer. Currently each event will be duplicated (clone()).
No, it should only be cloned if the machine defers the event. Also, if you allocate your event with new and assign it to an intrusive_ptr p and then pass *p to process_event() then the event should not be cloned.
4. A thread safe scheduler. It's hard to use hundreds of instances of the asynchronous_state_machine because each instance needs a thread. Correct me if I am wrong here.
? A single fifo_scheduler can service as many asynchronous state machines as you like.
5. Macros to define events, where all memebers are const. I've found that it's error prone to write it by hand again and again.
You mean the macro would save you from having to write const for each member? HTH, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.