Boost logo

Boost :

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

Johan Nilsson <johan.nilsson <at>> 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.


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



Boost list run by bdawes at, gregod at, cpdaniel at, john at