Hello Alexander, Wednesday, January 3, 2007, 11:45:15 PM, you wrote:
Andrey Semashev wrote:
Wednesday, January 3, 2007, 9:46:16 PM, you wrote:
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
So does any state machine - it has a limited set of types ;-)
To my mind, the default limit for "variant" is 10 types. A medium-scaled FSM may easily have more states. So if there would be some dispatching state that decides further behavior of the machine, we'd have a problem here. Of course, the example is a bit theoretical but I had something of that kind in my experience, yet not that big.
and it takes some time to dispatch the real type of the object it stores. It a resonable price for the flexibility.
I'd rather say, in many cases it is.
Besides, I'd like to keep the ability to return something useful for the user from "on_process".
IMO, it doesn't outweight an ability to have a transition table available at compile-time.
The fact is, it doesn't actually prevent you from having one.
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.
An ability to define one function for transitions from several states is more important than template handlers.
I can't agree with you here. First, transition maps don't prevent you from defining a transition that is applicable to more than one state. Moreover, you may define a transition that triggers on several events too. In fact, it is a far more flexible mechanism than trying to use state handlers for this purpose. Second, I found that template event handlers are very useful when the set of possible events is rather big and they are all (maybe, except several of them I'm interested in at the particular state) processed in a common way. Using event base classes and polymorphism isn't always suitable to solve the problem. From my point of view, performing a transition and processing an event are quite different and even may be orthogonal tasks. The first is aimed to control the internal state and behavior of the FSM, and the second implements the behavior.
I agree that id<...> is not convinient. I'd be happy to get rid of it.
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.
I couldn't build a sample program neither on gcc 3.4.6 nor on Intel Linux 8.1 so I can only guess that dynamic_cast<OtherState*>(this) would access OtherState from *this state.
Ah, yes, the "dynamic_cast" would do the trick. :) But this looks more like a hack rather than intended feature, doesn't it? Could you be more specific about your problems with ICC and GCC on Linux? I don't have such configurations at my disposal, so I would appreciate any help with these. Thank you. -- Best regards, Andrey mailto:andysem@mail.ru