"Andreas Huber" <ah2003@gmx.net> writes:
Hi Dave,
[snip]
After a brief glance, it looks like a very sophisticated and well-thought-out library.
Thanks :-)
I'd like to know if following state transitions require dynamic allocation or not.
By default (i.e. when you define states as demonstrated in the tutorial), a dynamic allocation happens in the course of every state entry. However, since users define all state classes themselves, they have full control over how each state will be allocated (see "Memory management customization" in the rationale).
OK, that's still dynamic allocation, but it may be good enough. Also, do I note that there's always function pointer indirection for event dispatch? While you clearly need something like that if there's an event queue, the MPL samples I posted earlier don't make you pay for that in the cases where you don't need it.
[snip]
Out of the box, state_machine<> does the following:
1. The exception is caught
By the state machine framework?
Yes.
Clarification in the text would be good.
2. In the catch block, an exception_thrown event is allocated on the stack
3. Also in the catch block, an immediate dispatch of the exception_thrown event is attempted.
Hum. So basically, any throwing code that could be invoked from processing exception_thrown and from processing some other event had better be re-entrant?
Yes. However, I don't think this will happen in practice. Code that is executed as a result of the processing of an exception_thrown event is typically very different from code that is executed during normal state machine operation. Moreover, if code reacting to an exception_thrown event throws itself an exception then this exception will under all circumstances be propagated to the state machine client. That is, error handling code does not have to be reentrant.
OK.
That is, possibly remaining events in the queue are dispatched only after the exception has been handled successfully
I don't understand the relationship here.
A state machine can post internal events (simple_state<>::post_event()) while processing an event. Those internal events are pushed into a queue and processed as soon as the state machine has finished processing the current event. If an exception is thrown while processing any of these events, the resulting exception_thrown event "overtakes" the still queued events.
OK.
4. If the exception was handled successfully
What does that mean? Who signals "successful handling", and how do they do it?
This is explained a bit further down under the title Successful exception handling. I agree that this is probably a bit hard to find. I've added a link in my version.
Thanks. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com