[boost] Re: Please, comment design decision of simple FSM

From: Alexander Nasonov (alnsn_at_[hidden])
Date: 2004-09-15 00:01:26

Andreas Huber wrote:
> David Abrahams wrote:
> >"Andreas Huber" <ah2003_at_[hidden]> writes:
> >>Wow! So simple and yet powerful. It naturally supports nested states
> >>and polymorphic events. I guess this could quite easily be developed
> >>into a fast & lightweight boost::fsm alternative. Cool!
> >
> >It's very close to the organization of the MPL FSM samples I have
> >posted in the past...

I saw them. They are cool :)

> Yep, I had noticed that. What I like better about Alexander's approach 
> is that the transition table is implemented with ordinary C++ what makes 
> it quite a bit more expressive than the MPL collections you used in your 
> examples. Don't get me wrong, I personally love MPL, but I've found that 
> the average programmer is easily scared away with even very simple MPL 
> constructs.

I didn't expected that simplicity. In order to check my ideas I need
some metaprogramming.
For example, if I number every call-operator (overload_id<N> in a first
argument), I can collect all states automatically (unique_at algorithm).
I can also collect all events (unique_at again) and move transition
table for those events to cpp file if a user puts static initializer in
Fsm class. I can also check with find_if and is_convertible if there is 
a match for given state and event. If not, I can dispatch to alternative.

If you have other ideas, please share them with me. I'm really
interested to make implementation more complex :)

> >only there's no dumb O(N) for_each dispatching
> >in my samples: they're O(1).
> 
> Unless I'm missing something one could easily modify Alexander's code to 
> be O(1) too...?

Yep

-- 
Alexander Nasonov