From: "Rob Stewart" <stewart@[...].com> 
>  From: "E. Gladyshev" <eegg@[...].net>
>  > From: "Rob Stewart" <stewart@[...].com>

[...]
>  > > So, OK, there is that slight difference, but why would you care?
>  >
>  > I don't think that it is a slight difference. If you make an assumption
>  > that all unhandled exceptions will eventually trigger
>  > stack unwinding, but a specific implementation doesn't do that,
>  > it is huge difference.
> 
>  Why would you want the non-deterministic behavior?

Whether I want it or not doesn't change anything.
All I am saying that it is implementation dependent and it is a big
difference.

[...]
> 
>  Why would you want terminate() to be called without stack
>  unwinding on those platforms that do it?  What does that get you?
>  I would think that boost::fsm's behavior, being more
>  deterministic, would be preferable.

There could be many reasons, just to list few of them.
1. Some platforms pose non-C++ exceptions as normal C++ exception.
    You don't always want those platfrom specific exceptions trigger
    a whole bunch of stuff in your program.
2. Your design assumes that all possible exceptions are known
    and you handle them. So any unhandled exception is a bug.
    It is not safe to trigger stack unwinding in a buggy environment.

These reasons could be of a particular importance in
control applications where state machines are a must.

But again whether I want it or not, the Standard allows
implementation where the stack unwinding
(for unhandled exceptions) never happens.

[...]
>  Does not unwinding the stack when terminate() is called, on
>  whatever platforms do that, gain you something that outweighs the
>  determinism and reuse of the boost::fsm approach?

Please see above.

Eugene

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