[boost] Re: Re: Re: Re: Finite state machine requirements

From: Andreas Huber (spam2002_at_[hidden])
Date: 2002-09-11 12:15:41

> Anyway, I don't believe it is up to the state machine framework to
> ensure that. I let the user decide how to control this since there are
> cases where data must be kept local to a state and there are cases where
> it is not.

I agree that it's not up to the framework to _ensure_ proper object
lifetime. However, I think it's up to the framework to provide support for
scoping (see below).

> It is like using FILE*. You can use a smart pointer or not,
> but it is up to you to decide when you are done with the data.
>
> I use a Property Map to store state variables. If scoping is important
> to you, it should not be difficult to define policies to describe data
> lifetimes. Then the framework can destroy data that has gone out of scope.

Ok, I guess this again boils down to our fundamental disagreement about what
should be done at compile-time. I assume that all your states still "run" in
the same compile-time context (the property map). Developing large state
machines where all states reside in the same context is similar to writing a
complex function without being able to use functional decomposition or local
blocks:
a) All stack-allocated resources can be used everywhere. There's neither
compile-time nor runtime checks to ensure proper lifetime.
b) All handle-managed resources can be used everywhere. Although it's
possible to find scoping errors at runtime (the handle is set to "NULL"
after deallocating the resource), there's still no way to find such problems
at compile-time.

Andreas