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

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

"Andreas Huber" <ah2003_at_[hidden]> wrote in message
news:c9321i$njh$1_at_sea.gmane.org...
> Rob Stewart wrote:
> > Andreas made the remark that tying construction to entry and
> > destruction to exit helps with scalability.  I imagine that means
> > the he's worried about a potentially large number of states in
> > some fsm's and that keeping all the state objects alive
> > simultaneously could be a bad idea.
>

This was exactly the same impression I've had all the time - somewhat
analogous to COM+ where objects have no own 'state' and are constantly
recreated or even reused,  IIRC.

> Ok, I guess I didn't express this clearly enough. When I mention
scalability
> I always refer to the fact that you can spread a state machine over
multiple
> translation units and that a change in one of these TUs will not trigger a
> recompilation of the whole state machine.

This should really be more clearly stated in the docs - perhaps even the
wording 'scalability' should be changed. You're referring to minimizing
compile-time dependencies, right?

 The two corner stones that enable
> this are:
> - State local storage. Every FSM object owns separate state objects. I.e.
> state objects are *not* shared between multiple FSM objects (as they are
in
> some FSM implementations)

The term "state local storage" feels a bit misleading to me - is that a
well-known term? I relate to thread local storage, which makes me think that
each state has some private storage accessible to only itself (well ok,
maybe it has - 'this'). Is another wording possible?

> - custom_reactions
>
> Whether or not states are also destructed when they are exited does not
make
> a difference here.

If that is the case; would it be possible to address the question by adding
a state_lifetime policy to e.g. the state_machine class?

// Johan