Re: [boost] [review] FSM Second Call for Reviews

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-09-01 12:16:12

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.