From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-02-24 17:44:10
Thanks for you review!
>> What could be added
>> (or removed) from the library?
> I'm with Simon in the desire to declare all transitions including
> guards and in-state reactions in the header (rather than just declare
> a custom reaction). It isn't just automated tools that find this
> easier to follow - it simplifies the process of doodling a transition
> diagram with one hand while scrolling through the code with the other
> - or reading the doodle and touchtyping the declarations. I think it
> is highly desirable that the full set of allowed transitions be
> clearly visible from declarations alone. The documentation suggests
> "Custom reactions can of course also be implemented directly in the
> state declaration, which is often preferable for easier browsing."
> but this breaks encapsulation unless the guard actually calls a
> number of sub-functions in a way similar to Simon's suggested
> templated guard.
Ok, I'll implement something like that, but it will take a while. I
think there are more important things that should come first (like e.g.
> Andreas has previously pointed out a problem in providing in-state
> reaction declarations in that any such transition is then forced to
> use an outer context (incomplete type otherwise) which seem somewhat
> odd for an in-state reaction, however I haven't actually found it to
> be a big problem in practice (innermost states tend to be empty).
> Maybe it would be sufficient to provide a declaration that simply
> specifies that a particular event is handled by an in-state reaction
> (ie. similar to the custom reaction declaration), but with the
> handler having no ability to return a transition object?
This has recently occurred to me also. I'll implement an in-state
reaction the way you suggest in the very near future.
>> * The library documentation contains
>> few not yet solved issues (name,
>> separating the library into two parts,
>> exception handling). What is you opinion here?
> Naming: Please keep UML out of it ;-). High Level is simply too
> vague. How about Matrioshka (a bit obscure I guess)...
> I don't think
> some unpronounceable abbreviation intended to distinguish it from
> other possible fsm libraries is useful.
Ok, noted. I now also lean more towards keeping fsm.
>> * Are there performance bottlenecks?
> The various performance tradeoffs are well described in the
> rationale. I wonder if there isn't some way of optimising empty (ie
> no associated context) states better to improve performance, but it
> isn't a big issue for me.
I can't see how at the moment (the often empty innermost states are
implemented differently already).
>> Does the library design fit requirements
>> of real-time systems?
> To the extent that anything that uses dynamic memory allocation does,
> yes. The documentation does cover the issues well. In long running
> (uptimes of months) soft real-time embedded systems, we are not
> seeing any problems (this is even without using custom allocators).
That's very interesting to hear! I would have expected you seeing memory
fragmentation problems within days. Could it be that the default
operator new of your platform does some pooling internally?
-- 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