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

From: Johan Nilsson (johan.nilsson_at_[hidden])
Date: 2004-05-27 04:43:06

"Andreas Huber" <ah2003_at_[hidden]> wrote in message
news:c930is$p44$1_at_sea.gmane.org...
> 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 :-).
> 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?) 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. Even
> worse, they must not even rely on how many times state ctors/dtors are
> called. Today they might be called exactly as often as entry()/exit() but
> tomorrow they might be called only exactly once. 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().

What's stopping me from always create them in constructor/delete in
destructor, then just init/deinit them (if necessary) in entry/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 follow you here; what's the analogy?

> 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:

By unspecified times I assume you mean that they are not created at the
'logical' state exit and entry. I'll look into the stopwatch example to see
what you're getting at (but having you describe the problems would be even
better).

> - 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".

In terms of speed, I've got no real opinions (so far). I guess it depends on
whatever fits the particular application in question - another reason for
policy-based state-lifetime management (if possible)?

> - Nobody has so far presented hard technical facts that support the view
> that mapping entry/exit to ctor/dtor is wrong.

<philosophical entry/>
For me, hard technical facts aren't everything. All software engineering is
an art and a craft as well, IMHO. Should one always choose a particular
design on hard technical facts only, or should you also trust your gut-level
feelings (open question)?
</philosophical entry>

// Johan