diff --git a/doc/DispatchCost.gif b/doc/DispatchCost.gif deleted file mode 100644 index 60389d9..0000000 Binary files a/doc/DispatchCost.gif and /dev/null differ diff --git a/doc/acknowledgments.html b/doc/acknowledgments.html index 7db7f09..4aa4072 100644 --- a/doc/acknowledgments.html +++ b/doc/acknowledgments.html @@ -20,15 +20,27 @@
Very special thanks go to Aleksey Gurtovoy, the developer of the ingenious meta programming library (boost::mpl). The interface as well as -the implementation of boost::fsm hugely benefit from Alekseys work. I would have given up long ago without mpl. -

I would also like to thank

+the implementation of boost::fsm hugely benefit from Alekseys work. I would have given up long ago without mpl. +Moreover, Aleksey's double dispatch implementation in +his FSM +framework gave me fresh ideas after I had come to the conclusion that my +dynamic_cast-based solution was too bloody bad +☺.

Special +thanks go to:

+

I would also like to thank:

+

Revised -19 May, 2003

+30 May, 2003

© Copyright Andreas Huber Dönni 2003. All Rights Reserved.

\ No newline at end of file diff --git a/doc/index.html b/doc/index.html index fa18360..03a83e9 100644 --- a/doc/index.html +++ b/doc/index.html @@ -36,12 +36,19 @@
  • State-local storage
  • Customizable resource acquisition
    • -

    The library is not yet complete. The following is still lacking:

    - +

    The library is not yet complete. Here is the current to-do list:

    +
      +
    1. The library does not yet check for invalid transitions between different + orthogonal regions, although the documentation claims otherwise.
      2. +
    2. Factor out several functions in the state_machine class + template into base classes to reduce code size in projects with many different state machines.
      3. +
    3. Add a concurrent_state_machine class template to model a state machine + running in its own thread.
      4. +
    4. Add regression tests.
      5. +
    5. Port to gcc.
      6. +
    6. Add reference documentation.
      7. +
    7. Add support for shallow/deep history.
      8. +

    This is a preliminary submission to encourage feedback. All comments are most welcome!

    Contents

    @@ -53,7 +60,7 @@

    Revised -19 May, 2003

    +30 May, 2003

    © Copyright Andreas Huber Dönni 2003. All Rights Reserved.

    \ No newline at end of file diff --git a/doc/rationale.html b/doc/rationale.html index a46bc3c..7166fa8 100644 --- a/doc/rationale.html +++ b/doc/rationale.html @@ -24,12 +24,14 @@
    Why yet another state machine framework?
    State-local storage
    Dynamic configurability
    -
    Resource usage
    -
    Determinism
    Error handling
    User actions: Member functions vs. function objects
    -
    Memory management
    +
    Speed versus scalability tradeoffs
    +
    Memory management customization
    +
    RTTI customization
    Double dispatch
    +
    Resource usage
    +
    Limitations

    Introduction

    Most of the design decisions made during the development of this library are the result of the following requirements.

    @@ -52,12 +54,14 @@
  • produce a customizable reaction when a C++ exception is propagated from user code.
  • support sequential and concurrent state machines and leave it to the - end-user which thread a concurrent state machine will run in.
    • -
  • support the development of arbitrarily large and complex state machines. This means that multiple developers should be able to work on + + user which thread a concurrent state machine will run in.
    • +
  • support the development of arbitrarily large and complex state machines. Multiple developers should be able to work on the same state machine simultaneously.
  • allow the user to customize all resource management so that the library could be used for applications with hard real-time requirements.
  • enforce as much as possible at compile time. Specifically, invalid state machines should not compile.
    • +
  • offer reasonable performance for a wide range of applications.

    • Why yet another state machine framework?

    Before I started to develop this library I had a look at the following frameworks:

    @@ -76,11 +80,13 @@

    boost::fsm currently satisfies all requirements except for 3 (history not yet implemented) and 5 (support for threading not yet implemented).

    State-local storage

    -

    This not yet widely known state machine feature is enabled by the fact that every state in boost::fsm is represented by a class. Upon -state-entry, an object of the class is constructed and the object is later destructed when the state machine exits the state. Any data that -is useful only as long as the machine resides in the state can (and should) thus be a member of the state. This feature paired with the -ability to spread a state machine over several translation units makes it possible to have multiple developers simultaneously working on the -same state machine. Moreover, local changes to the machine layout no longer lead to recompilation of the whole machine. 

    +

    This not yet widely known state machine feature is enabled by the fact that every state in boost::fsm +is represented by a class. Upon state-entry, an object of the class is +constructed and the object is later destructed when the state machine exits the +state. Any data that is useful only as long as the machine resides in the state +can (and should) thus be a member of the state. This feature paired with the +ability to spread a state machine over several translation units makes possible +the virtually unlimited scalability of boost::fsm. 

    In most existing FSM frameworks the whole state machine runs in one environment (context). That is, all resource handles and variables local to the state machine are stored in one place (normally as members of the class that also derives from some state machine base class). For large state machines this often leads to the class having a huge number of data members most of which are needed only @@ -89,17 +95,18 @@ recompilations of the whole state machine. 

    Dynamic configurability

    Two types of state machines

    Why not use a dynamically configurable FSM library for all state machines?

    One might argue that a dynamically configurable FSM framework is all one ever needs because any state machine can be implemented -with it. However, due to its nature such a framework has a number of disadvantages when used to implement static state machines:

    +with it. However, due to its nature such a framework has a number of disadvantages when used to implement static machines: