Hello Alexander, Wednesday, January 3, 2007, 9:46:16 PM, you wrote:
Andrey Semashev wrote:
Although I was pointing out something different in my previous post, returning a state or a reference to it has one major drawback. What "on_process" should return if the next state depends on the event contents?
It would return variant<State1&, State2&, /* ... */ >. Visual representation of FSM would be fuzzy but it still better than no visual representation at all.
The "variant" has a limited set of possible types and it takes some time to dispatch the real type of the object it stores. Besides, I'd like to keep the ability to return something useful for the user from "on_process". IMHO, transition maps exist to make FSM transitions visible at the first glance. No need to involve event handlers into this and take away several useful features by this, such as return values and template event handlers, and add these "id< ... >" arguments on top of that.
Besides, when returning a reference, where should the state object be stored? For example, in a state machine object.
It may not be the current state member since it is destroyed on state exit. So, once again, it may only be a member of some outer state. Not necessarily. It may be a member of a state machine.
Actually, it's the way Boost.FSM is implemented except that it doesn't allow to access one state from another and therefore ensures encapsulation. -- Best regards, Andrey mailto:andysem@mail.ru