"Alexander Nasonov" <alnsn@yandex.ru> writes:
I wrote:
That's possible. If your automata is essentially value-based (for example, FSM for searching subsrings in a string) then it's better to use something else. But, in a modern world, type identity plays an important role too. For example, if someone is developing FSM silimar to mine where each event has additional params (eg, EvActive may have priority), what would he/she prefer, to invent his/her own protocol to transmit event code and event specific params or to use existing technology like CORBA and to send objects?
Oopps, I mixed states and events up. I answer again.
David Abrahams wrote:
"Alexander Nasonov" <alnsn@yandex.ru> writes:
struct Fsm { Running operator()( id<1>, Passive, EvActivate ) const; Stopped operator()( id<2>, Running, EvStartStop ) const; Running operator()( id<3>, Stopped, EvStartStop ) const; Stopped operator()( id<4>, Active, EvReset ) const; // ... };
It's not directly relevant to your overloads component, but I'm very curious as to why you want to use _types_ to represent states. It seems counter-productive because of course types are static, and states are, well, stateful. Don't you end up wasting time and code translating between states and types?
That's not exactly true. States are _types_ only at compile-time. At runtime, they are objects passed to correspondent call operator. Objects may be stateful.
struct Running { /* stateful */ }; struct Stopped { /* stateful */ };
Even more confusing; now you need a dynamic allocation to represent and change the current state of the machine. I suppose you could use variant, but I never understood why people want to put state _inside_ of states -- it doesn't match up with the domain abstraction of state machines. The state's identity should be enough. -- Dave Abrahams Boost Consulting www.boost-consulting.com