From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-30 03:32:22
Jeff Flinn wrote:
>> What is your evaluation of the design?
>> What is your evaluation of the documentation?
> My view of the design is limited to what is described in the
> documentation. I was a little dismayed that some of the basic features
> that I needed are considered Advanced features such as sharing state and
> accessing the current state from outside the state machine. These are
> very easily accomplished in the TMP and StateChart libraries.
It's just a name for the section. Everything that didn't fit into
Tutorial went into that section.
> section on accessing state is not sufficient for me to determine which
> state the fsm is in between calls to process().
Huh? There is a section that tells precisely how to do this. The
is_in_state and get_current_state_type methods fill your requirement.
> The data sharing
> approach between sibling states using a virtual base class is
> perplexing... there's no discussion of just what is the structure of the
> state machine.
Actually, this feature is one of those I love in the library.
The description of the structure is given in the "Common data and
methods among states" section. I admit, however, there's no graphical
representation of the design, but if I drew precisely what the structure
is, I think, it would confuse you even more.
>> Do you think the library should be accepted as a Boost library?
> No. I'd prefer that the performance and missing functionality be added
> to improve the existing StateChart library, and/or a true transition
> table approach be provided ala the TMP book's transition table.
I don't think that with current implementation approach Boost.StateChart
can be optimized to the degree of Boost.FSM. As for TMP approach, I've
shown that it is representable with Boost.FSM.
> dislike FSM's verbose interface along with it's procedural leaning
Having a look at your example, I don't find Boost.FSM portion to be much
more or less verbose than others.