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