Boost logo

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at