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

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