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

From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-05-27 06:54:42

Johan Nilsson <johan.nilsson <at> esrange.ssc.se> writes:

> What's stopping me from always create them in constructor/delete in
> destructor, then just init/deinit them (if necessary) in entry/exit?

The fact that most classes (well-designed ones) don't have init/deinit.

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

A lot of the C++ ctors/dtors design is about automation and error-avoidance. 
If you have non-POD data members in your class, C++ gives you a guarantee that 
they are constructed/destructed at the right times. With entry()/exit() you'd 
need to do that manually again (just like you had to in Turbo Pascal). Ugly!

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

Yes.

> > - 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)?

Everything is possible. The question is: What exactly is the advantage? What 
are the use-cases?

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

To me good design is 10% ideas, imagination and, yes, gut-level feelings. The 
other 90% are technical facts. I believe the initial effort when crafting an 
interface is always gut-based, afterwards comes the long and tedious period of 
verifying (with hard facts) that your gut feelings are right. If there are no 
hard facts to justify a feature then I unceremoniously throw it out. Not doing 
so means overloading an interface and elevating the risk of overwhelming 
potential users with unnecessary baggage.

Regards,

Andreas