"Andreas Huber" <ah2003@gmx.net> writes:
Dear Boosters
I think boost::fsm has finally reached a state that is worthy of a formal review.
The .zip can be found here:
http://boost-sandbox.sf.net/fsm.zip
The docs are also available online:
http://boost-sandbox.sf.net/libs/fsm
As always: Feedback is highly welcome.
After a brief glance, it looks like a very sophisticated and well-thought-out library. I'd like to know if following state transitions require dynamic allocation or not. I also have some questions about this:
Exception handling ------------------
Exceptions can be propagated from all user code except from state exit actions (mapped to destructors and destructors should virtually never throw in C++).
That seems like a bad limitation, and for me it calls into question the idea of mapping state exit to destructors. Can you explain why that's the right design?
Out of the box, state_machine<> does the following:
1. The exception is caught
By the state machine framework?
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?
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.
4. If the exception was handled successfully
What does that mean? Who signals "successful handling", and how do they do it?
the state machine returns to the client normally. If the exception could not be handled successfully, the original exception is rethrown so that the client of the state machine can handle the exception
This behavior is implemented in the exception_translator class template, which is the default for the ExceptionTranslator parameter of the state_machine class template. It was introduced because users would want to change this on some platforms to work around buggy exception handling implementations (see Discriminating exceptions).
Interesting; I'll have to look at that... -- Dave Abrahams Boost Consulting http://www.boost-consulting.com