RE: [OBORONA-SPAM] RE: [boost] Re: overloads-20050207.tar.gz

From: Alexander Nasonov (alnsn_at_[hidden])
Date: 2005-02-12 06:17:10

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 */ };

Fsm fsm;
Passive initial;

Running r = fsm(enable_all(), initial, EvActivate());
Stopped s = fsm(enable_all(), r, EvStartStop());
r = fsm(enable_all(), s, EvStartStop());
s = fsm(enable_all(), r, EvReset());
--
Alexander