Hello Alexander, Tuesday, December 19, 2006, 12:46:01 AM, you wrote:
Andrey Semashev wrote:
Thanks for the article. It dropped me a thought of a way of improving my automatic transitions support in runtime. You're welcome! What idea, BTW?
Well, currently there's a two-phase transition lookup: a compile-time search of a transition rule in the map (with "is_applicable" MPL predicate) and a runtime check wether the statically found rule will actually trigger the transition (a static function "is_allowed"). You might have seen it in the library docs. This "is_allowed" is implemented in each transition rule. It takes an event and returns true if the transition should be performed or false otherwise. So it only allows or denies the library to perform the transition. The idea is to pass a reference to the current state to the function and let it switch the state itself (due to this change of semantic I will have to change its name to somewhat like "transit"). Although this exposes states' implementation to transitions, this would add more flexibility. The dark side of the change is that I'll probably have to add another layer of dispatch of the event (it will cost an additional function call via a function pointer in runtime) and probably some increase of compilation time.
Although, I still don't catch the point of creating/destroying state objects during transitions. This can even be inconvenient if a state is intended to be visited more than once. It's easy to draw a graph by analyzing signatures of transitions. It's not possible with switch_to<State>() because these calls can appear anywhere in the on_process body. This is very important use case, IMO.
Yes, I agree. That is why there is a support for transition maps in my implementation that I've spoken of above. Although in many cases the switch_to approach is more simple and flexible.
You can always define a state with a pointer to the state's data. This is usually a good distinction especially if states hierarchy is used to model inner and outer states. In this case, states hierarchy in often not related to state's data hierarchy.
A pointer to the state's data doesn't help if the state is actually destroyed when being left (the pointer is freed and the data is lost). And storing such pointer in a place somewhere out of the state (i.e. in a base state, a state machine or its some common storage like virtual bases in my implementation) means that data is exposed and is no longer specific to the state. IMO, this breaks the natural state encapsulation that is one of the main ideas of FSM concept. -- Best regards, Andrey mailto:andysem@mail.ru