From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-05-25 05:23:53
David Abrahams <dave <at> boost-consulting.com> 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?
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.
Regards,
Andreas