Now I get it. This is, was I saw in the debugger. OK. It's a little messy for me. I'm afraid that there is no way, to change this. I'm thinking about a special reaction in these orthogonal states to route the event "sidewards" instead of downwards. Any chance?
UML is quite clear on the order how reactions are checked (always from the/an innermost state outward). Now, if we come to the conclusion that your use-case is sufficiently common *and* if there is no easier way to achieve the behavior you want, I might consider adding such a beast. But again, that'll be 1.42 *at* *best*.
From a high-level POV, could you please describe the behavior you are trying to implement? If you are worried about posting app details in a public forum, you can send it to me by PM. Thanks.
? A single fifo_scheduler can service as many asynchronous state machines as you like.
Yes, you're right. I was thinking about a state machine that isn't bound to one thread. I had the strand concept from the asio library in mind. You can post a work item (event) asynchonous but have a guarantee that execution is serialized.
Ok, can you implement what you want with the current version or do you require different behavior? [snip]
Ignore the tracer_. This is only a helper object to trace the event ctor/dtor. I think it's a good idea to keep all members of an event const.
In general, I tend to agree. However in this case making the data members const doesn't really add much, as events are always passed as const to reactions anyway. So, I'm not sure whether such a macro would be used much. -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.