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