"Andreas Huber" <ah2003@gmx.net> wrote in message news:c8ogtj$npe$1@sea.gmane.org...
Dear Boosters
I think boost::fsm has finally reached a state that is worthy of a formal review.
The .zip can be found here:
http://boost-sandbox.sf.net/fsm.zip
The docs are also available online:
http://boost-sandbox.sf.net/libs/fsm
As always: Feedback is highly welcome.
I've only read through the tutorial and glanced at the rationale, so bear with me if I've missed something out. I have not looked at the implementation. In brief it looks like some real good work has been invested into the development of the library! Some personal opinions though (of which I think some has been discussed otherwere in this thread): 1. No real support for runtime-defined fsm:s (yes, I've read the rationale). This is something that I personally _could_ live without, but would prefer not having to. I've definitely have had the need for (and implemented) a totally runtime-defined fsm. The problem would be how to implement this generically without the need for common interface classes ... hmmm. <speculation/>How about implementing two models within boost::fsm (dynamic + static model), or allow a hybrid approach?</speculation> 2. I'd prefer the states to be more loosely coupled (i.e. not having to know about other states at the same or higher levels, or the fsm itself). The fsm could take care of transitioning based on incoming events, current state and the abstract "result" of the event[*]. This way the state transitioning could be extended/changed without rewriting the states themselves. Exception: outer states should have some knowledge about inner states (they might be considered state-machines themselves). I guess by now my ignorance of the implementation shines through -> are enclosing states actually state machines already in boost::fsm? 3. The entering/exiting of a state is modeled by the construction/destruction of a state object (see details in subsections). 3.1 Entering/exiting a state should be decoupled from creating/destroying the state objects themselves. I can see the simplicity in creating the states when they are entered etc, but for me states live continuously within a fsm; they are just entered/leaved at certain points in time. And - if they happen to be active states (i.e. run by a thread or running a worker thread themselves) they might need to perform background activities even when they are inactive. 3.2. The initialization of a state could be potentially expensive; needing to initialize (construct) a state each time it is entered could result in intolerable performance (consider a state needing to setup a TCP connection). This could be handled in the current fsm implentation (I believe) by keeping such things in the fsm or enclosing state - but there's that coupling again. 3.3 I prefer (to the utmost extent) that initialization/construction is performed once, which should be during the application initialization. Once done, I'd like to know that my state objects (in this case) are constructed and that the will remain so for the rest of the execution; no memory allocation errors; no socket creation errors; ... etc .. during runtime [basically the same as 3.2 above]. (aka "do or die"). 4. Built-in support for active states would be great. Perhaps you've been reading Miro Samek's great articles in CUJ (if not, please do so). Providing at least some rudimentary (but expandable) support for active states would be ... great (am I reapeating myself or what). <speculation/>Provide an active_state base for states needing their own thread; provide an active_fsm that keeps a worker thread that is running the currently active state (which would require some cooperation from the states to implement transitions); or ... </speculation>. 5. If the dynamic stuff's never going to happen; perhaps provide an example on how to implement a runtime-defined fsm on top of boost::fsm (you briefly mention the possibility in the rationale) [related to 1]. [*] By abstract results I just mean some magical stuff telling the state machine what the result of the "reaction" was. It could possibly be allowed for a state to explicitly exit by using using the imaginary "return exit_state(succeeded_result())". Just my 0.05?. // Johan