From: David Abrahams (dave_at_[hidden])
Date: 2004-05-25 09:25:17
Andreas Huber <ah2003_at_[hidden]> 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.
>> > 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
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk