[boost] Re: [prereview request][fsm]

From: Robert Bell (belvis_at_[hidden])
Date: 2004-05-26 17:34:57

Andreas Huber wrote:
> Robert Bell wrote:
> 
>>Here's one argument in favor of entry()/exit() over
>>constructor/destructor. If you use constructors/destructors, your
>>hands
>>will be tied if someday you want to change your mind about the
>>implementation of state entry and exit constructing and destructing
>>states (a couple of alternatives have been discussed here, such as
>>constructing states when they're entered but not destroying them when
>>they're exited). If instead you implement entry and exit with entry()
>>and exit() member functions, it doesn't matter if the states are
>>constructed and destructed as they are now, constructed at entry point
>>and destroyed at machine destruction time, or constructed all at once
>>at machine construction time.
>>
>>I don't have any idea if this flexibility is important or not, but if
>>I
>>was implementing fsm, I'd consider it.
> 
> 
> Believe me, I *am* considering it. I even started dreaming about it :-).

That happens to me sometimes too. Sometimes I think it's cool. Other 
times I think it means I need a vacation. ;-)

> However, no matter from what angle I start to think this through I always
> end up with the same bad feeling. If we introduce entry()/exit() for the
> reasons you give (more flexibility for optimization?)

More flexibility to change the implementation, for any reason (not 
necessarily optimization). By using constructors and destructors for 
entry and exit, you're telling users that fsm guarantess that States 
will be constructed and destroyed at specific times, which means that 
for all time fsm must provide those guarantees.

> this essentially means
> to tell the users that they must not under any circumstances rely on when
> exactly constructors and destructors of state objects are called.

Keep in mind that it's entirely possible that I'm missign something. 
That said, they can't rely on when exactly constructors and destructors 
are called today.

> Even
> worse, they must not even rely on how many times state ctors/dtors are
> called.

They can't rely on the number of times they're called now.

 > Today they might be called exactly as often as entry()/exit() but
> tomorrow they might be called only exactly once.

None of these issues having to do with when and how many times 
constructors and destructors are called sound bad to me; why would 
anyone care?

 > This means that most
> non-POD data members of states need to be created on the heap, as you
> otherwise wouldn't have a chance to create them inside entry() and destroy
> them inside exit(). And believe me, you definitely need to do that when you
> design non-trivial FSMs. Therefore, to me entry()/exit() means falling at
> least halfway back into medieval times where you always had to explictly
> call constructors and destructors yourself (Turbo Pascal).

I don't quite see it this way myself, but in any event, this is a 
concern for the implementer of fsm, not a user of fsm.

> Please have a look at the StopWatch example and imagine the additional
> complexity introduced with entry()/exit() (and ctors/dtors called at
> unspecified times). I only want to go there if there are compelling reasons:
> - I believe that boost::fsm is already reasonably fast (and there is still
> some potential for optimization). Nobody who is actually using it has ever
> complained that it is too slow. Someone has even reported that it performs
> "very well".

I'm not so concerned about performance; if the interfaces are reasonably 
clean, it can always be optimized later.

> - Nobody has so far presented hard technical facts that support the view
> that mapping entry/exit to ctor/dtor is wrong. To the contrary, I think I
> have almost proved in my discussion with Dave that exit actions must not
> fail and that you *can* recover from failing entry actions.

I'm not so sure there _are_ hard technical facts; there are just two 
different interface choices, each with different tradeoffs.

I'm sure you've thought this out more than I have. I'm just coming from 
a gut-level reaction I have to linking entry/exit to 
construction/destruction. It just feels weird. For example, if entry and 
exit actions are things a state "does", then I'd expect them to be 
overridable; constructors and destructors can't be overridden.

(In the past, when I've implemented state machines I've made Action a 
separate class; that way, Actions are attached to States, which makes it 
easier to reuse Actions in different States.)

Don't take this as me saying you're doing it wrong or that fsm is 
ill-designed or anything like that. I just wanted to raise a point I 
have not yet seen raised, and as I said, you've obviously spent a lot 
more time working on this than I. I don't quite understand the objection 
to entry() and exit() member functions, but then again I don't have to 
understand it for fsm to proceed.

Bob