[boost] Re: FSM Review

From: David B. Held (dheld_at_[hidden])
Date: 2005-03-14 23:34:31

Iain K. Hanson wrote:
> [...]
> 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.

Yes.  And sometimes there is more than one best in the breed.

> The primary philosophy in C++ is you don't pay for what you don't use.

...And yet, we have iostreams.

> Andreas has deliberately taken a different approach. He has chosen
> to go for the all singing, all dancing heavey weight approach.

...Much like shared_ptr<>, which got into TR1.  And I dare say that
shared_ptr<> is used in far more performance sensitive contexts than
the FSM.  If we declared that shared_ptr<> is the end-all, be-all
smart pointer for C++, I would be as unhappy as you are.

> 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 ).

And if that were a deal-breaker, people wouldn't be using the
library, would they?  Apparently, there are applications where
these are not the critical metrics, and people have already found
use for it.

> 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.

But can you provide all the other features of the FSM proposal?  If
not, then you're comparing apples to oranges, right?

> 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

I'm not quite sure what you're saying here, but clearly there is
precedent for solutions at different granularities/complexities
/performance tradeoffs in Boost.  Consider tokenizer/regex/spirit.
Consider compose/bind/lambda.  If you think that Boost needs a
low-level FSM that concentrates on performance over abstraction,
you may be right.  But if you think that it does not need an FSM
library that focuses on abstraction and ease of use, it would
appear that some users might disagree with you.

Dave