Hi all,
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? If yes, I have a bug (hard to detect). If
no, I have to rewrite my code.
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)
2. Calling the state constructor with an event. something like transit<S>(
event );
3. A process_event() method that acceepts an intrusive pointer. Currently
each event will be duplicated (clone()).
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.
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.
6. Thanks!
Pirx!
"Andreas Huber"
Hi
I have a state [A] with three orthogonal substates [X,Y,Z]. The states [A] and [X] provide custom reactions for an event [E]. If processing event [E] the state machine calls first the custom reaction in [A]. This method returns with forward_event() ; After this the custom reaction in [A] is called again. And then custom reaction in [X] is called.
This is a little cumbersome. Why is the custom reaction in [A] called twice?
And why is the outermost state called first? It would be something easier to work vice versa. First the more "specialized" inner states could do there work and then the "generalized" outer states can do the everything else.
This behavior is as designed, for an in-depth description please see:
http://www.boost.org/libs/statechart/doc/reference.html#process_event
Reaction search always starts with an *arbitrary* innermost state and then first works its way outward. Only when the outermost state has been reached is the next innermost state checked for a suitable reaction. This behavior stems form the fact that all reactions defined in outer states are "inherited" by their direct and indirect inner states, as mandated by the UML standard.
What are you trying to achieve? Maybe I can suggest a more suitable implementation.
HTH,
-- Andreas Huber
When replying by private email, please remove the words spam and trap from the address shown in the header.