Boost logo

Boost :

From: Scott Woods (scottw_at_[hidden])
Date: 2002-09-09 16:32:36


> class Open;
> class Locked : public boost::fsm::state< Locked, Lock >,
> public boost::fsm::transition< Locked, Lock::EvUnlock, Open
>
> {
> public:
> Locked( context_ptr_type pContext ) : base_type( pContext ) {}
> };
>
> class Open : public boost::fsm::state< Open, Lock >,
> public boost::fsm::transition< Open, Lock::EvLock, Locked
>
> {
> public:
> Open( context_ptr_type pContext ) : base_type( pContext ) {}
> };
>

I understand (mostly) what is involved here but still struggle with the
sheer quantity
of framing/cruft/... required to implement a machine. I have followed the
discussion
so far and realise there is a real history to this. GOF and UML are good
references to wave around when presenting new work. GOF is a pretty abstract
reference (rightly so ;-) while UML (FSM) is a formal language (?) for
specifying
state machines. My question - is there no potential to "de-normalize" from
these
ideals, with the goal of making it easier for the developer? I have had some
exposure
to FSMs (with SDL) and feel more prepared to tackle a FSM library than
others
might be. So if I find it hard then how is it going to be for someone on
their first
time up? OTOH we (developers) always want everything to fit in 3 lines ;-).

Wondered about the commitment to UML FSMs but I suppose that SDL cant
really compete, in terms of who-is-using-what modelling techniques.

The type of FSMs that I have been dealing with can be characterized as; a
large,
dynamic community of co-operating FSMs distributed over a network of
computing
devices. That's pretty "waffley" but hopefull captures the essence of it. My
biggest
dilemma with your FSM library is that I don't think it has these kind of
goals (no
library seems to BTW ;-) and its also quite difficult to divide the signal
processing
(i.e. FSM events) from the distributed nature of my problem space (e.g.
network
transports and messaging systems).

Any thoughts in those areas?

SW


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk