"Andreas Huber" <ah2003@[...].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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost