Re: [boost] Re: FSM Review

From: Iain K. Hanson (ikh_at_[hidden])
Date: 2005-03-06 21:16:12

Hi Andreas,

On Sun, Mar 06, 2005 at 07:42:59PM +0100, Andreas Huber wrote:
> Hi Iain,
> 
> Thanks for your review!
> 
I'm sorry it had to be negative but I did try to warn you when we discussed
this previously.

[snip]

> So, if you or anyone else has
> a good idea how all the requirements can be satisfied while keeping the
> performance comparable to hand-written FSMs I'd be very interested to
> hear it.

Thanks for the history that I've sniped. I understand fully what you mean. I
have had the similar problems with my sockets library. The problem IMHO is a
lack of meta-programming skills ( I've certainly suffered from ). However,
Czarnecki & Eisenecker showed that C++ is Church Turring complete at compile
time so as long as this conjecture holds it has to be doable.

The approach that I believe would have the greatest chance of sucess would
be to use layered ( GenVoca style ) implementation mixed with CRTP to 
provide two way communication between the layers to form a policy based design.
Users would then use a DSL to specify there requirements and a generator
would build the FSM.

> > I have a serrious problems with this library. FSM is a design pattern
> > and
> > they can be spellt in a wide variety of ways. E.g state transition
> > tables Deterministic Finite Automata, Coloured Petri Nets, and Harrel
> > / UML state charts. There are equallly, many ways of implementing
> > FSMs. Calling this library the FSM libray would be like submitting
> > multimap and calling it the collections library.
> 
> That's fine with me. As I wrote in the known issues section I wouldn't
> mind changing the name. I guess it is best to vote on this.

A name change would only solve part of my problem with this submission. I
strongly believe that the C++ you only pay what is absolutely necessary
for what you use can not be breached for a boost library. 
particularly as I have said above, with better meta-programmingi, constant
time event dispatch and transition have to be achiveable given CT completness.
I.e. event dispatch should idealy be a single indirection but I could live 
with double dispatch and a transition should idealy be an assignment.

I'll address the reat tomorrow as I'm tired and it is late.

regards

/ikh