|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2005-02-12 08:54:16
"Alexander Nasonov" <alnsn_at_[hidden]> 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_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk