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

> > > Are you proposing that an active state should still be represented by an 
> > > object, 
> > 
> > I don't have enough knowledge of the FSM domain to say whether that's
> > a good design or not; I have to trust you that it makes sense to have
> > a correspondence between states and distinct types whose instances'
> > lifetimes correspond to the time spent in the state.
> 
>  That an active state is represented by an object is crucial to satisfy the 
>  scalability requirements. Otherwise adding a variable that is used only in a 
>  part of the machine would lead to the recompilation of the whole state machine.

OK.

> > > which acquires resources and executes entry actions in its
> > > constructor, releases resources in its destructor but executes exit
> > > actions in a separate function, which is called just before
> > > destructing the state object?
> > 
> > Yes, that's basically what I was saying.
> 
>  This is certainly doable. However, I'm unsure whether the current design 
>  allows a you-don't-pay-for-what-you-don't-use implementation of such a 
>  feature. Plus, I'm still not convinced that this feature would be used more 
>  than rarely. Do you have some real-world use cases in mind?

Unfortunately I'm not so familiar with what exit actions in FSMs are
typically used for, but from an abstract point of view I don't think
of resource releasing as an "action".  If you were writing this stuff
in a GC'd language, for the most part, you wouldn't devote any exit
action code to resource releases.  So I figure there must be some
other reason people want exit actions, and since they seem
symmetrical to entry actions in some ways, I don't see why you'd want
to prohibit exceptions there.  If anything, I'd want to prohibit
exceptions in entry actions, since those can lead to the FSM being in
a state from which it's impossible to continue.  At least with exit
actions, you can stay where you are and keep all your FSM's abstract
invariants intact.

>  If this is needed only rarely I'd rather have users work around the
>  problem by setting a boolean and posting an error event in a failing
>  exit action and then testing that boolean in all following exit
>  actions.

Eeeeew, that's gross.  Sorry, but that just smells like an awful
hack.  Why not just call the state object's exit() member function if
it has one?

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

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