Re: [boost] Proposal to add a Boost.FSM library

From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-01-03 16:41:31

Hello Alexander,

Wednesday, January 3, 2007, 11:45:15 PM, you wrote:

> Andrey Semashev wrote:
>> Wednesday, January 3, 2007, 9:46:16 PM, you wrote:
>> 
>> > It would return variant<State1&, State2&, /* ... */ >. Visual
>> > representation of FSM would be fuzzy but it still better than no
>> > visual representation at all.
>> 
>> The "variant" has a limited set of possible types 

> So does any state machine - it has a limited set of types ;-)

To my mind, the default limit for "variant" is 10 types. A
medium-scaled FSM may easily have more states. So if there would be
some dispatching state that decides further behavior of the machine,
we'd have a problem here. Of course, the example is a bit theoretical
but I had something of that kind in my experience, yet not that big.

>> and it takes some time
>> to dispatch the real type of the object it stores.
> It a resonable price for the flexibility.

I'd rather say, in many cases it is.

>> Besides, I'd like to
>> keep the ability to return something useful for the user from
>> "on_process".

> IMO, it doesn't outweight an ability to have a transition table
> available at compile-time.

The fact is, it doesn't actually prevent you from having one.

>> IMHO, transition maps exist to make FSM transitions visible at the
>> first glance. No need to involve event handlers into this and take
>> away several useful features by this, such as return values and template
>> event handlers, and add these "id< ... >" arguments on top of that.

> An ability to define one function for transitions from several states is
> more important than template handlers.

I can't agree with you here. First, transition maps don't prevent you
from defining a transition that is applicable to more than one state.
Moreover, you may define a transition that triggers on several events
too. In fact, it is a far more flexible mechanism than trying to use
state handlers for this purpose.
Second, I found that template event handlers are very useful when the
set of possible events is rather big and they are all (maybe, except
several of them I'm interested in at the particular state) processed
in a common way. Using event base classes and polymorphism isn't
always suitable to solve the problem.

From my point of view, performing a transition and processing an event
are quite different and even may be orthogonal tasks. The first is
aimed to control the internal state and behavior of the FSM, and the
second implements the behavior.

> I agree that id<...> is not convinient. I'd be happy to get rid of it.

>> Actually, it's the way Boost.FSM is implemented except that it doesn't
>> allow to access one state from another and therefore ensures
>> encapsulation.

> I couldn't build a sample program neither on gcc 3.4.6 nor on Intel
> Linux 8.1 so I can only guess that dynamic_cast<OtherState*>(this) would
> access OtherState from *this state.

Ah, yes, the "dynamic_cast" would do the trick. :) But this looks more
like a hack rather than intended feature, doesn't it?

Could you be more specific about your problems with ICC and GCC on
Linux? I don't have such configurations at my disposal, so I would
appreciate any help with these. Thank you.

-- 
Best regards,
 Andrey                            mailto:andysem_at_[hidden]