Jeff Flinn wrote:
Andrey Semashev wrote:
Jeff Flinn wrote: So so I would use is_in_state<extracted_triplet>(); in the extractor::extracted method?
Yes.
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.
Agreed.
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?
AFAIR, StateChart uses dynamic memory allocation for event delivery and state switching. Aside from event delivery overhead, this means that states are destroyed and constructed on each transition, which leads to overhead from the user's data that may be contained in the states. I'm also not sure which approach of event/state dispatching StateChart uses, but I'm pretty sure that it is less efficient than a mere indirect call through a pointer taken from an array by index. This is because StateChart uses RTTI (built-in or ad-hoc) to dispatch events in run time. This isn't for an inefficient implementation of StateChart (in fact, I am sure the author have put a lot of effort to achieve the current performance), it's just a consequence of a quite extensive feature set. The question is, do you always need them?
Can you direct me to that discussion/presentation on emulating the TMP approach?
We discussed the matter with David during this review. Here's the link to one of my posts with two code samples. http://tinyurl.com/5mn2gq
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",
"void on_process" is effectively replaced with "void set1" and so on.
and "switch_to" not present in the TMP approach.
True. Boost.FSM wouldn't have had "switch_to" too, if transition table was used.