From 58d6bbb184a5357d5dcd10eadda366c50877696a Mon Sep 17 00:00:00 2001
From: Andreas Huber Special thanks go to: Thanks for feedback and/or encouragement go to: David Abrahams, Bohdan, Reece Dunn, Jeff Garland, Douglas Gregor, Gustavo
-Guerra, Aleksey Gurtovoy, Chris Russell and Scott Woods.
+
lightweight_mutex,
intrusive_ptr) boost::fsm is building on
Revised -12 October, 2003
+17 November, 2003© Copyright Andreas Huber Dönni 2003. All Rights Reserved.
diff --git a/doc/configuration.html b/doc/configuration.html new file mode 100644 index 0000000..15defb6 --- /dev/null +++ b/doc/configuration.html @@ -0,0 +1,89 @@ + + + + + + + + +
+
+
+ |
+
+ The boost::fsm library+Configuration+ |
+
The library uses several configuration macros in +<boost/config.hpp>, +as well as one configuration macro meant to be supplied by the application. +Moreover, two commonly available compiler options also have an impact on the +available features.
+
+ state_cast<>() leads to a compile time error (state_downcast<>()
+ is still available). Moreover, BOOST_FSM_USE_NATIVE_RTTI must
+ not be defined simultaneouslyThe following macro may be defined by an application using the library:
+| Macro | +Meaning | +
BOOST_FSM_USE_NATIVE_RTTI |
+ When defined, the library no longer uses its own
+ speed-optimized RTTI implementation. Instead, native C++ RTTI is employed.
+ This has the following effects:
|
+
Revised + 30 November, 2003 +
+© Copyright Andreas Huber 2003.
+ + + + diff --git a/doc/definitions.html b/doc/definitions.html index d0c9c5a..5a9fe19 100644 --- a/doc/definitions.html +++ b/doc/definitions.html @@ -24,18 +24,49 @@The boost::fsm documentation uses a lot of terminology specific to state +machines. Most of it is equal to the one used in the UML specifications. This +document contains only definitions for terminology not used by UML.
+The direct context of a state is either its outer state or the state +machine. In the latter case the state is an outermost state.
+The innermost common outer state of two states is the first direct or +indirect outer state that both states have in common. Also known as Least +Common Ancestor (UML).
+An innermost state is a state that does not itself have inner states. Also
+known as leaf state or simple state (UML). Note that
+boost::fsm::simple_state is not a model of the UML simple state.
An in-state reaction is a reaction that neither +exits nor enters any states. Also known as inner transition or internal +transition (UML).
+An outermost state is a state that does not itself have outer states. Note +that an outermost state is different from a UML top state. A state machine can +have an arbitrary number of the former but only exactly one of the latter. +boost::fsm only supports outermost states.
An FSM library supports polymorphic events if events can inherit from - each other without restrictions and allows the definition of - reactions for leafs and nodes of the resulting event inheritance - tree.
-Example (using a hypothetical fsm library, as boost::fsm does not support - polymorphic events):
-struct EvButtonPressed : Event // node +An FSM library supports polymorphic events if events can inherit from each +other without restrictions and allows the definition of reactions for +leafs and nodes of the resulting event inheritance tree.
+Example (using a hypothetical fsm library, as boost::fsm does not support +polymorphic events):
+struct EvButtonPressed : Event // node { /* common button pressed properties */ }; @@ -43,14 +74,51 @@ struct EvPlayButtonPressed : EvButtonPressed {}; // leaf struct EvStopButtonPressed : EvButtonPressed {}; // leaf struct EvForwardButtonPressed : EvButtonPressed {}; // leaf-If a state machine needs to react whenever any button (including - the ones that may be added in the future) is pressed, a reaction for
- -- EvButtonPressedcan be defined.
If a state machine needs to react whenever any button (including the
+ones that may be added in the future) is pressed, a reaction for
+EvButtonPressed can be defined.
A reaction consists of all the side effects caused by the processing of one +event. Reactions can be categorized as follows:
+Note that it is possible to mix a reaction of type 1 with one of the other +types (the in-state reaction is always executed first) but it is not possible +to mix a reaction of type 2-4 with anything else but type 1.
+A reaction is always associated with exactly one state type and exactly one +event type.
+A state is unstable from the moment when it has been entered until just +before its last direct inner state is entered.
+A state machine is unstable if at least one of its currently active states +is unstable. This is the case during the following three operations:
+Under normal circumstances a state machine has Run-To-Completion semantics,
+that is, processing of an event is fully completed before the machine returns
+to the client or before the next event is dequeued. Therefore, a state machine
+is usually only unstable when it is busy processing an event and becomes
+stable again right before it has finished processing the event. However, this
+can not be guaranteed when either transition actions or entry actions fail
+(exit actions cannot fail). Such a failure is reported by an event, which must
+be processed while the state machine is unstable. However, exception event
+processing rules ensure that a state machine cannot be unstable when it
+returns to the client (see state_machine<>::process_event for
+details).
Revised - 12 October, 2003 + 09 December, 2003
© Copyright Andreas Huber Dönni 2003.
diff --git a/doc/faq.html b/doc/faq.html index 291215a..621ea8e 100644 --- a/doc/faq.html +++ b/doc/faq.html @@ -42,7 +42,8 @@No. Although events can be derived from each other to write common code -only once, reactions can only be defined for most-derived events.
+only once, reactions can only be +defined for most-derived events.Example:
template< class MostDerived > struct EvButtonPressed : fsm::event< MostDerived > @@ -249,7 +250,7 @@ destructors of additional bases are called before recursion employed by state base destructors can alter the order of destruction.
Revised -12 October, 2003
+01 December, 2003© Copyright Andreas Huber Dönni 2003. All Rights Reserved.
diff --git a/doc/index.html b/doc/index.html index 3c9ce59..b361a7a 100644 --- a/doc/index.html +++ b/doc/index.html @@ -53,14 +53,12 @@ include:
The library is almost functionally complete. However, the following is -still in the making:
+The library is functionally complete. However, the following is still in +the making:
state_machine class template to reduce
code size in projects with many different state machines12 December 2003:
+12 October 2003:
rtti_policy<> from the
@@ -111,7 +119,7 @@ still in the making:
Revised -12 October, 2003
+12 December, 2003© Copyright Andreas Huber Dönni 2003. All Rights Reserved.
diff --git a/doc/rationale.html b/doc/rationale.html index 9ec3acd..bc4c4e9 100644 --- a/doc/rationale.html +++ b/doc/rationale.html @@ -48,8 +48,8 @@ are the result of the following requirements.boost::fsm should ...
Consider the following state configuration:

Both states define entry actions (x() and y()). Whenever state A becomes -current, a call to x() will immediately be followed by a call to y(). y() -could depend on the side-effects of x(). Therefore, executing y() does not -make sense if x() fails. This is not an esoteric corner case but happens in +active, a call to x() will immediately be followed by a call to y(). y() could +depend on the side-effects of x(). Therefore, executing y() does not make +sense if x() fails. This is not an esoteric corner case but happens in every-day state machines all the time. For example, x() could acquire memory the contents of which is later modified by y(). There is a different but in terms of error handling equally critical situation in the Tutorial under @@ -229,11 +233,14 @@ code is simply boring and quite unnecessary.
react functions
- are sent to the current state.In the last two cases the state-machine is not in a stable state when the exception event is generated and leaving it there (e.g. by ignoring the @@ -245,25 +252,25 @@ code is simply boring and quite unnecessary.
rethrown.The design of the asynchronous_state_machine<> and
-worker<> class templates follow from the requirements:
The design of the asynchronous_state_machine and worker
+class templates follow from the requirements:
worker<> class template is not associated with a particular
+ The worker class template is not associated with a particular
thread. Instead, users can choose to either call worker<>::operator()
directly from the current thread or pass an appropriate function object to a
new thread.
- worker<> object. The state machines will then share the same
+ worker object. The state machines will then share the same
thread-safe queue and event loop.
- worker<>.BitMachine measurements with more states and with different levels of optimization:
-