Andrey Semashev wrote:
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.
The 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.
Ok, not sure why I had trouble reading through that earlier, other than I had a hard time finding this section whenever I went to look for it. Perhaps if you moved the Table of contents to the top of the docs, as it is it gets lost in the clutter. So so I would use is_in_state<extracted_triplet>(); in the extractor::extracted method?
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.
Perhaps a Design/Rationale section would better convey that this section describes the overall architecture of the system.
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.
What leads you to the conclusion that StateChart's performance could not be improved to that of FSM's? Can you direct me to that discussion/presentation on emulating the TMP approach?
I dislike FSM's verbose interface along with it's procedural leaning paradigm.
Having a look at your example, I don't find Boost.FSM portion to be much more or less verbose than others.
I'd say it's on par with StateChart. Like StateChart, there's boilerplate repetition of base classes, "void on_process", and "switch_to" not present in the TMP approach. Jeff