"Andreas Huber" <ah2003@[...].net>  writes:

>  David Abrahams wrote:
> >> Yes, but only at the cost of making the current interface (and
> >> implementation) more complex (we'd need to have at least a separate
> >> exit() function, right?).
> >
> > No.  At the moment we're just talking about whether A1 is justified.
> > Whether or not exit actions should use destructors is a separate
> > question.
> 
>  Is it? In the current design the state machine object owns the state objects
>  (it does so for good reasons). How can you destruct the state
>  machine object without destructing the state objects (and thus inevitably
>  also exiting them and terminating the state machine as a result)?

You're still collapsing separate concepts.  According to the
definition you posted, termination has nothing to do with destruction
of anything; it's about making a transition to the FSM's "final"
state.  Conceptually, state (machine) destruction is independent of
state machine termination.

Your A1 says that they shouldn't be independent (and on that basis you
conclude that state destructors and their exit actions must be
linked).  I'm challenging A1.  I have no argument with the idea that
any state objects should be destroyed when the FSM is destroyed.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

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