Boost logo

Boost Users :

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-07-07 04:58:56

Dave wrote:
> the FAQ illustrates how to modify the existing layout of an FSM, but I
> doubt whether it would be possible to implement the main FSM in the
> main exe and then dynamically load dlls to add inner/sub-states to
> existing states; since the state transition/reactions have to be
> specified as template parameters.

Why do you think that the transition/reaction specification interface is a
problem? The FAQ item shows that you can have a base FSM that uses a virtual
function to delay the decision where to transit from a given state (Idle) when
a specific event occurs (EvStart). The base FSM (PumpBase) would be compiled
into the main exe. If you want to modify the behavior in a dll, all you need
to do is to derive from the base FSM and inside the virtual function override
you transit to the desired state.
Of course, for all this to work the main exe would need to have a means of
constructing an object of the derived class (MyPump) that was loaded from the
dll. This is easy enough to do with a factory.

>> Out of curiosity: Would you care to describe what kind of
>> application you need such a library for?
> This is probably off-topic for this ng but I'll provide my reasons so
> you can decide if they're reasonable or not.
> The application I mentioned original post is a call control
> application, in fact several of them. (Naturally each application is
> maintained by a group of developers) Each of the applications has a
> flat Fsm with many states. My goal is to design a framework that has a
> main Fsm that is common to all the call control applications (with
> points of customization pre-defined) and then dynamically load DLLs to
> customize the behavior (by adding inner/sub-states) of the Fsm. The
> obvious advantage of doing so would be code reuse.

All this should be possible with Boost.Statechart, see above.

> Another reason to
> do so is that if a customization for a specific customer is needed
> (say add a few states to the fsm), only a few DLLs need to be
> modified/added, whereas in the existing design the main application
> has to be modified and recompiled. In this way the customization may
> be done by a developer who does not have full access to the source
> code/statechart, all he/she needs to know is the interface of the
> "point of customization".


> Dynamic configurabliity aside, the application I'm working on is a
> call control application, so I only need one instance of the state
> machine, one instance of each state and use context objects to store
> state information for each call.

Maybe there's just a terminology misunderstanding but I don't see the benefit
of the context object. In fact, the use of a context object here looks like a
common antipattern, a "winnebago" object (stolen from Jeff Garland). You'll
find more on this here (search for the first occurrence of "heuristic" and
read what follows):

> When I skimmed through the statechart
> tutorial I see that the "Entry" and "Exit" functions are implemented
> using the constructor and destructor of the simple_state class, so I
> suppose that each state object is constructed when entered and
> destructed when exited.

Exactly. This mechanism allows multiple developers to work on the same state
machine without even knowing of each other. Very often you need additional
variables (counters, etc.) that are associated with a state or a group of
states. A developer working on a part of the machine can then simply add such
a variable to an appropriate state class and never needs to modify a global
context class or the state machine class.

> I'm not sure.. if a state is entered and
> exited repeatedly, say in the stopwatch example, whether the object
> construction/destruction incurs an unecessary cost. If I'm wrong,
> please correct me.

That really depends on your application. If you have small flat fsms with no
or little additional context associated with states then this cost can be
prohibitive indeed. From what you have described so far this is not the case
in your application. I don't think the construction/destruction overhead will
be noticeable in your app, given that there is a lot of network communication
involved (I assume). BTW, you can easily customize memory management to cut
down the new/delete overhead.

HTH & Regards,

Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header. 

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at