Boost logo

Boost :

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-03-07 13:58:33


Hi Peter

Thanks for your review!

Peter Petrov wrote:
> To me, the design is good and follows naturally from the objectives of
> the library. It imposes some restrictions, although they can be
> overcome if necessary (for me it has not been necessary). For example,
> machines
> don't recognize polymorphic events, therefore they cannot "forward"
> unknown events to another machine. This can be circumvented by using a
> "wrapper" event around such events, which works, but only with
> asynchronous machines.

There's going to be a much nicer way of reacting to all events. I will
add event_base specializations for all reactions.

> Another example is the way that state machines
> are inherited - it's not very flexible and only allows altering how a
> state machine reacts to an already recognized event. One cannot add
> support for new events, except using again the "wrapper event" trick.

Support for new events should be possible indirectly when you have a
derived FSM transition to a new substate. However, I admit that it is
cumbersome.

> * The library documentation contains
> few not yet solved issues (name,
> separating the library into two parts,
> exception handling). What is you opinion here?
>
>
> The name (boost::fsm, Boost.FSM) is fine for me. Regarding separating
> the library into two parts, I prefer it being separated, since the
> Worker part is useful by itself.

Ok, noted.

> A possible problem is that states are constructed using operator
> new(). The documentation clearly states that, and the library allows
> overcoming the issue by specifying a custom allocator for the state
> machine, as
> well as writing custom operator new()'s for all state classes. I
> personally am against the second requirement and think that it
> complicates things too much. Specifying a custom allocator for the
> state machine should be enough.

Doing so would make it impossible to have separate memory management for
states, which I think is sometimes desirable when there's at most one
object of an FSM (as I explain in the rationale). I should probably
measure the difference, it could well be insignificant.

Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header. 

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk