E. Gladyshev wrote:

>  As for unstable states.
>  Does this idiom mean that any exception event handling
>  state must be considered as an implicit *inner* state of
>  any other state that throws?
>  So that *only* the exception handling states
>  can be considered as *most inner* states.

No. Please have a look at http://tinyurl.com/2uzs5 (the whole section on
Exception Handling) again. I think it clearly explains how it all works.

>  I think that one of the most important goals of
>  the state machines design is to achieve
>  a completely deterministic behavior.

Yes, this is important for me also.

>  Doesn't your default exception handling
>  idiom compromise this objective?

Do you think so because finding a handler for an exception might take
non-deterministic time? That is true on some platforms. On others you *can*
establish upper limits for finding a handler.
I chose the default this way because I believe that a majority of the users
will not have deterministic reaction time requirements. In real-time
projects you often disable exceptions anyway so the problem won't arise. I
will add a remark that real-time projects should consider not using
exceptions or check that the compilers exception handling implementation is
deterministic.

Regards,

Andreas


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