Re: [boost] Re: FSM Review

From: Iain K. Hanson (ikh_at_[hidden])
Date: 2005-03-14 21:49:31

Hi Dave,

On Mon, Mar 14, 2005 at 06:13:19PM -0600, David B. Held wrote:
> 
> One thing that bothers me about the performance discussion is that
> some parties seem to imply that there exists a single best point in
> the design space, and that the proposed library has not found it.
> Given all the different constraints and values that can differ from
> application context to application context and user to user, I hardly
> see how such a stance is justifiable.  Without having followed the
> discussion too closely or reviewed the library in any depth, I would
> have to say that my impression is that Andreas has put together a
> reasonably solid library with decent rationale for his design
> decisions.  And isn't that Boost is interested in?  Quality libraries
> that put correctness first and performance second?  I don't believe
> Andreas has at any point claimed that his library is the fastest
> possible implementation of FSMs in existence, so why should it be
> held up to that goal?
> 

There is no doubt ( in my mind ) that Andreas has done some very good work.
The issue is whether this library is suitable for acceptance into boost.
IIUC boost is predominately about best of breed libs.

The primary philosophy in C++ is you don't pay for what you don't use.
Andreas has deliberately taken a different approach. He has chosen to
go for the all singing, all dancing heavey weight approach.

He has explained his approach on this list. You pay for State Specific 
Storage whether you want it or not. You currently get non-linear event
dispatch ( without orthaganal regions ) if you use outer states. And you get
horrible performance on transitions ( with loss os state specific storgge
when you transition out of a state ).

I know that if Inhand write a GOF state pattern I can get close to the 
scaleability of the FSM lib but with constant time event dispatch through
a single indirection and can change state through a single assignment.

FSM is the domain but whether itnis spelt STT of StateChart is irrelevent
one can be mechanucally collapsed to the other. But the fsm proposal 
does not do this. 

If we have a StateChart lib in boost it should scale as wel as any other
library in booat

IMHO

/ikh