diff --git a/doc/HTML/ch01.html b/doc/HTML/ch01.html index 3509c7d..d26d28b 100644 --- a/doc/HTML/ch01.html +++ b/doc/HTML/ch01.html @@ -1,6 +1,6 @@ - Chapter 1. Founding idea
Chapter 1. Founding idea
Prev Part I. User' guide Next

Chapter 1. Founding idea

Let's start with an example taken from the C++ Template Metaprogramming + Chapter 1. Founding idea

Chapter 1. Founding idea
Prev Part I. User' guide Next

Chapter 1. Founding idea

Let's start with an example taken from the C++ Template Metaprogramming book:

class player : public state_machine<player>
 { 
   // The list of FSM states enum states { Empty, Open, Stopped, Playing, Paused , initial_state = Empty }; 
diff --git a/doc/HTML/ch02.html b/doc/HTML/ch02.html
index 52c1c20..a285ed2 100644
--- a/doc/HTML/ch02.html
+++ b/doc/HTML/ch02.html
@@ -1,6 +1,6 @@
 
       
-   Chapter 2. UML Short Guide
Chapter 2. UML Short Guide
Prev Part I. User' guide Next
Chapter 2. UML Short Guide
Table of Contents
What are state machines?
Concepts
State machine, state, transition, event 
Submachines, orthogonal regions, pseudostates 

+   Chapter 2. UML Short Guide
Chapter 2. UML Short Guide
Prev Part I. User' guide Next
Chapter 2. UML Short Guide
Table of Contents
What are state machines?
Concepts
State machine, state, transition, event 
Submachines, orthogonal regions, pseudostates 

                         History 
Completion transitions / anonymous
                         transitions
 Internal transitions 

                         Conflicting transitions 
State machine glossary
What are state machines?
State machines are the description of a thing's lifeline. They describe the
diff --git a/doc/HTML/ch02s02.html b/doc/HTML/ch02s02.html
index 805cabe..6a06000 100644
--- a/doc/HTML/ch02s02.html
+++ b/doc/HTML/ch02s02.html
@@ -1,6 +1,6 @@
 
       
-   Concepts
Concepts
Prev Chapter 2. UML Short Guide Next
Concepts
Thinking in terms of state machines is a bit surprising at first, so let us
+   Concepts
Concepts
Prev Chapter 2. UML Short Guide Next
Concepts
Thinking in terms of state machines is a bit surprising at first, so let us
                     have a quick glance at the concepts.
State machine, state, transition, event 
A state machine is a concrete model describing the behavior of a system.
                         It is composed of a finite number of states and transitions.

                         
A simple state has no sub states. It can have data, entry and exit
diff --git a/doc/HTML/ch02s03.html b/doc/HTML/ch02s03.html
index 9f82003..3aa8102 100644
--- a/doc/HTML/ch02s03.html
+++ b/doc/HTML/ch02s03.html
@@ -1,6 +1,6 @@
 
       
-   State machine glossary
State machine glossary
Prev Chapter 2. UML Short Guide Next
State machine glossary

+   State machine glossary
State machine glossary
Prev Chapter 2. UML Short Guide Next
State machine glossary

States

There is also a macro for states. This macro has 2 arguments, first the expression defining the state, then the state (instance) name:

BOOST_MSM_EUML_STATE((),Paused)

This defines a simple state without entry or exit action. You can provide in the expression parameter the state behaviors (entry and exit) @@ -166,7 +163,7 @@ Empty_impl const Empty;

Notice also that we defined a method named activ could use with the functor front-end, the second is the state method name, the third is the eUML-generated function, the fourth and fifth the return value when used inside a transition or a state behavior. You can - now use this inside a transition:

Empty == Open + open_close / (close_drawer,activate_empty_(target_))

Wrapping up a simple state machine and first complete examples

You can reuse the state machine definition method from the standard + now use this inside a transition:

Empty == Open + open_close / (close_drawer,activate_empty_(target_))

Wrapping up a simple state machine and first complete examples

You can reuse the state machine definition method from the standard front-end and simply replace the transition table by this new one. You can also use eUML to define a state machine "on the fly" (if, for example, you need to provide an on_entry/on_exit for this state machine as a functor). @@ -197,7 +194,7 @@ Empty_impl const Empty;

Notice also that we defined a method named activ The BOOST_MSM_EUML_DECLARE_ATTRIBUTE macro, to which we will get back shortly, declares attributes given to an eUML type (state or event) using the attribute - syntax.

Defining a submachine

Defining a submachine (see tutorial) with + syntax.

Defining a submachine

Defining a submachine (see tutorial) with other front-ends simply means using a state which is a state machine in the transition table of another state machine. This is the same with eUML. One only needs define a second state machine and reference it in the transition @@ -208,7 +205,7 @@ Empty_impl const Empty;

Notice also that we defined a method named activ machine, for example:

BOOST_MSM_EUML_DECLARE_STATE_MACHINE(...,Playing_)
 typedef msm::back::state_machine<Playing_> Playing_type;
 Playing_type const Playing;

We can now use this instance inside the transition table of the containing - state machine:

Paused == Playing + pause / pause_playback

+ state machine:

Paused == Playing + pause / pause_playback

Attributes / Function call

We now want to make our grammar more useful. Very often, one needs only very simple action methods, for example ++Counter or Counter > 5 where Counter is usually defined as some attribute of the class containing the @@ -262,7 +259,7 @@ BOOST_MSM_EUML_DECLARE_ATTRIBUTE(DiskTypeEnum,cd_type)

This declares two This method could also have an (or several) argument(s), for example the event, we could then call activate_empty_(target_ , event_).

More examples can be found in the terrible compiler stress test, the timer example or in the iPodSearch with eUML - (for String_ and more).

Orthogonal regions, flags, event deferring

Defining orthogonal regions really means providing more initial states. To + (for String_ and more).

Orthogonal regions, flags, event deferring

Defining orthogonal regions really means providing more initial states. To add more initial states, “shift left” some, for example, if we had another initial state named AllOk :

BOOST_MSM_EUML_DECLARE_STATE_MACHINE((transition_table,
                                      init_ << Empty << AllOk ),
@@ -314,7 +311,7 @@ BOOST_MSM_EUML_DECLARE_ATTRIBUTE(DiskTypeEnum,cd_type)

This declares two attributes_ << no_attributes_, configure_<< deferred_events ), player_)

A tutorial - illustrates this possibility.

+ illustrates this possibility.

Customizing a state machine / Getting more speed

We just saw how to use configure_ to define deferred events or flags. We can also use it to configure our state machine like we did with the other front-ends:

  • configure_ << no_exception: disables @@ -326,7 +323,7 @@ BOOST_MSM_EUML_DECLARE_ATTRIBUTE(DiskTypeEnum,cd_type)

    This declares two with eUML does this for the best performance.

    Important note: As exit pseudo states are using the message queue to forward events out of a submachine, the no_message_queue option cannot be used with state machines - containing an exit pseudo state.

Completion / Anonymous transitions

Anonymous transitions (See UML + containing an exit pseudo state.

Completion / Anonymous transitions

Anonymous transitions (See UML tutorial) are transitions without a named event, which are therefore triggered immediately when the source state becomes active, provided a guard allows it. As there is no event, to define such a @@ -334,7 +331,7 @@ BOOST_MSM_EUML_DECLARE_ATTRIBUTE(DiskTypeEnum,cd_type)

This declares two example: 

State3 == State4 [always_true] / State3ToState4
 State4 [always_true] / State3ToState4 == State3

Please have a look at this example, which implements the previously - defined state machine with eUML.

Internal transitions

Like both other front-ends, eUML supports two ways of defining internal transitions:

  • in the state machine's transition table. In this case, you + defined state machine with eUML.

Internal transitions

Like both other front-ends, eUML supports two ways of defining internal transitions:

  • in the state machine's transition table. In this case, you need to specify a source state, event, actions and guards but no target state, which eUML will interpret as an internal transition, for example this defines a transition internal to @@ -355,7 +352,7 @@ struct Open_impl : public Open_def the standard alternative, adding orthogonal regions, because event dispatching will, if accepted by the internal table, not continue to the subregions. This gives you a O(1) dispatch - instead of O(number of regions).

Other state types

We saw the build_state + instead of O(number of regions).

Other state types

We saw the build_state function, which creates a simple state. Likewise, eUML provides other state-building macros for other types of states:

  • BOOST_MSM_EUML_TERMINATE_STATE takes the same arguments as BOOST_MSM_EUML_STATE and defines, well, a terminate @@ -395,7 +392,7 @@ struct Open_impl : public Open_def 

    entry_pt_(SubFsm2,PseudoEntry1) == State1 + event4

    For exit points, it is again the same syntax except that exit points are used as source of the transition: 

    State2 == exit_pt_(SubFsm2,PseudoExit1) + event6

    The entry tutorial - is also available with eUML.

Helper functions

We saw a few helpers but there are more, so let us have a more complete description:

  • event_ : used inside any action, the event triggering the + is also available with eUML.

Helper functions

We saw a few helpers but there are more, so let us have a more complete description:

  • event_ : used inside any action, the event triggering the transition

  • state_: used inside entry and exit actions, the entered / exited state

  • source_: used inside a transition action, the source state

  • target_: used inside a transition action, the target @@ -433,7 +430,7 @@ struct Open_impl : public Open_def MSM_EUML_METHOD or MSM_EUML_FUNCTION will create a correct functor. Your own eUML functors written as described at the beginning of this section will also work well, except, for the - moment, with the while_, if_then_, if_then_else_ functions.

Phoenix-like STL support

eUML supports most C++ operators (except address-of). For example it is + moment, with the while_, if_then_, if_then_else_ functions.

Phoenix-like STL support

eUML supports most C++ operators (except address-of). For example it is possible to write event_(some_attribute)++ or [source_(some_bool) && fsm_(some_other_bool)]. But a programmer needs more than operators in his daily programming. The STL is clearly a must have. Therefore, eUML comes in @@ -462,7 +459,7 @@ struct Open_impl : public Open_def current state has an attribute m_src_it (an iterator). If this iterator != fsm.m_src_container.end(), process OneSong on fsm, copy-constructed from state.m_src_it which we - post-increment

Writing actions with Boost.Phoenix (in development)

It is also possible to write actions, guards, state entry and exit + post-increment

Writing actions with Boost.Phoenix (in development)

It is also possible to write actions, guards, state entry and exit actions using a reduced set of Boost.Phoenix capabilities. This feature is still in development stage, so you might get here and there some surprise. Simple cases, however, should work well. What will not work diff --git a/doc/HTML/ch03s05.html b/doc/HTML/ch03s05.html index 1745ad1..5ba587a 100644 --- a/doc/HTML/ch03s05.html +++ b/doc/HTML/ch03s05.html @@ -1,6 +1,6 @@ - Back-end

Back-end
Prev Chapter 3. Tutorial Next

Back-end

There is, at the moment, one back-end. This back-end contains the library + Back-end

Back-end
Prev Chapter 3. Tutorial Next

Back-end

There is, at the moment, one back-end. This back-end contains the library engine and defines the performance and functionality trade-offs. The currently available back-end implements most of the functionality defined by the UML 2.0 standard at very high runtime speed, in exchange for longer compile-time. The @@ -8,11 +8,11 @@ capabilities allowing the framework to adapt itself to the features used by a given concrete state machine. All unneeded features either disable themselves or can be manually disabled. See section 5.1 for a complete description of the - run-to-completion algorithm.

Creation

MSM being divided between front and back-end, one needs to first define a + run-to-completion algorithm.

Creation

MSM being divided between front and back-end, one needs to first define a front-end. Then, to create a real state machine, the back-end must be declared: 

typedef msm::back::state_machine<my_front_end> my_fsm;

We now have a fully functional state machine type. The next sections will - describe what can be done with it.

Starting and stopping a state + describe what can be done with it.

Starting and stopping a state machine

The start() method starts the state machine, meaning it will activate the initial state, which means in turn that the initial state's entry behavior will be called. We need the start method because you do not @@ -23,7 +23,7 @@ the algorithm run once. The iPodSearch example uses this possibility.

The stop() method works the same way. It will cause the exit actions of the currently active states(s) to be called.

Both methods are actually not an absolute need. Not calling them will simply cause your first entry or your last exit action not to be - called.

Event dispatching

The main reason to exist for a state machine is to dispatch events. For + called.

Event dispatching

The main reason to exist for a state machine is to dispatch events. For MSM, events are objects of a given event type. The object itself can contain data, but the event type is what decides of the transition to be taken. For MSM, if some_event is a given type (a simple struct for example) and e1 and @@ -34,14 +34,14 @@ an event of type some_event, you can simply create one on the fly or instantiate if before processing: 

my_fsm fsm; fsm.process_event(some_event());
 some_event e1; fsm.process_event(e1)

Creating an event on the fly will be optimized by the compiler so the - performance will not degrade.

Active state(s)

The backend also offers a way to know which state is active, though you + performance will not degrade.

Active state(s)

The backend also offers a way to know which state is active, though you will normally only need this for debugging purposes. If what you need simply is doing something with the active state, internal transitions or visitors are a better alternative. If you need to know what state is active, const int* current_state() will return an array of state ids. Please refer to the internals section to - know how state ids are generated.

Serialization

A common need is the ability to save a state machine and restore it at a + know how state ids are generated.

Serialization

A common need is the ability to save a state machine and restore it at a different time. MSM supports this feature for the basic and functor front-ends, and in a more limited manner for eUML. MSM supports boost::serialization out of the box (by offering a serialize @@ -110,7 +110,7 @@ std::ofstream ofs("fsm.txt"); serializing must be done in a stable state, when no event is being processed. You can serialize during event processing only if using no queue (deferred or event queue).

This example shows a state machine which we serialize after processing an - event. The Empty state also has some data to serialize.

Base state type

Sometimes, one needs to customize states to avoid repetition and provide a + event. The Empty state also has some data to serialize.

Base state type

Sometimes, one needs to customize states to avoid repetition and provide a common functionality, for example in the form of a virtual method. You might also want to make your states polymorphic so that you can call typeid on them for logging or debugging. It is also useful if you need a visitor, like @@ -133,7 +133,7 @@ std::ofstream ofs("fsm.txt"); 

struct player_ : public msm::front::state_machine<player_,my_base_state>

You can also ask for a state with a given id (which you might have gotten from current_state()) using const base_state* get_state_by_id(int id) const where base_state is the one you just defined. You can now - do something polymorphically.

Visitor

In some cases, having a pointer-to-base of the currently active states is + do something polymorphically.

Visitor

In some cases, having a pointer-to-base of the currently active states is not enough. You might want to call non-virtually a method of the currently active states. It will not be said that MSM forces the virtual keyword down your throat!

To achieve this goal, MSM provides its own variation of a visitor pattern @@ -172,18 +172,18 @@ struct my_visitable_state the accept function is to contain a parameter passed by reference, pass this parameter with a boost:ref/cref to avoid undesired copies or slicing. So, for example, in the above case, call:

SomeVisitor vis; sm.visit_current_states(boost::ref(vis));

This example uses a - visiting function with 2 arguments.

Flags

Flags is a MSM-only concept, supported by all front-ends, which base + visiting function with 2 arguments.

Flags

Flags is a MSM-only concept, supported by all front-ends, which base themselves on the functions: 

template <class Flag> bool is_flag_active()
 template <class Flag,class BinaryOp> bool is_flag_active()

These functions return true if the currently active state(s) support the Flag property. The first variant ORs the result if there are several orthogonal regions, the second one expects OR or AND, for example:

my_fsm.is_flag_active<MyFlag>()
-my_fsm.is_flag_active<MyFlag,my_fsm_type::Flag_OR>()

Please refer to the front-ends sections for usage examples.

Getting a state

It is sometimes necessary to have the client code get access to the +my_fsm.is_flag_active<MyFlag,my_fsm_type::Flag_OR>()

Please refer to the front-ends sections for usage examples.

Getting a state

It is sometimes necessary to have the client code get access to the states' data. After all, the states are created once for good and hang around as long as the state machine does so why not use it? You simply just need sometimes to get information about any state, even inactive ones. An example is if you want to write a coverage tool and know how many times a state was visited. To get a state, use the get_state method giving the state - name, for example: 

player::Stopped* tempstate = p.get_state<player::Stopped*>();

or 

player::Stopped& tempstate2 = p.get_state<player::Stopped&>();

depending on your personal taste.

State machine constructor with arguments

You might want to define a state machine with a non-default constructor. + name, for example: 

player::Stopped* tempstate = p.get_state<player::Stopped*>();

or 

player::Stopped& tempstate2 = p.get_state<player::Stopped&>();

depending on your personal taste.

State machine constructor with arguments

You might want to define a state machine with a non-default constructor. For example, you might want to write: 

struct player_ : public msm::front::state_machine_def<player_> 
 { 
     player_(int some_value){…} 
@@ -209,7 +209,7 @@ player p(boost::ref(data),3);
                         where some data is passed:
player p( back::states_ << Playing(back::states_ << Song1(some_Song1_data)) , 
           boost::ref(data),3);
It is also possible to replace a given state by a new instance at any time
                         using set_states() and the same syntax, for example:
-                        
p.set_states( back::states_ << state_1 << ... << state_n );
An example making intensive use of this capability is provided.

Trading run-time speed for + 

p.set_states( back::states_ << state_1 << ... << state_n );

An example making intensive use of this capability is provided.

Trading run-time speed for better compile-time / multi-TU compilation

MSM is optimized for run-time speed at the cost of longer compile-time. This can become a problem with older compilers and big state machines, especially if you don't really care about run-time speed that much and would @@ -240,7 +240,7 @@ BOOST_MSM_BACK_GENERATE_PROCESS_EVENT(mysubmachine)

  • events move to a separate header as all machines use it

    • -

    Compile-time state machine analysis

    A MSM state machine being a metaprogram, it is only logical that cheking +

    Compile-time state machine analysis

    A MSM state machine being a metaprogram, it is only logical that cheking for the validity of a concrete state machine happens compile-time. To this aim, using the compile-time graph library mpl_graph (delivered at the moment with MSM) from Gordon Woodhull, MSM provides several compile-time checks:

    • Check that orthogonal regions ar truly orthogonal.

    • Check that all states are either reachable from the initial @@ -254,12 +254,12 @@ BOOST_MSM_BACK_GENERATE_PROCESS_EVENT(mysubmachine)

    • explicit entry / pseudo entry state declaration.

      The author's advice is to enable the checks after any state machine structure change and disable it again after sucessful analysis.

      The following example provokes an assertion if one of the first two lines - of the transition table is used.

    Enqueueing events for later + of the transition table is used.

    Enqueueing events for later processing

    Calling process_event(Event const&) will immediately process the event with run-to-completion semantics. You can also enqueue the events and delay their processing by calling enqueue_event(Event const&) instead. Calling execute_queued_events() will then - process all enqueued events (in FIFO order).

    You can query the queue size by calling get_message_queue_size().

    Customizing the message queues

    MSM uses by default a std::deque for its queues (one message queue for + process all enqueued events (in FIFO order).

    You can query the queue size by calling get_message_queue_size().

    Customizing the message queues

    MSM uses by default a std::deque for its queues (one message queue for events generated during run-to-completion or with enqueue_event, one for deferred events). Unfortunately, on some STL implementations, it is a very expensive container in size and copying @@ -270,14 +270,14 @@ BOOST_MSM_BACK_GENERATE_PROCESS_EVENT(mysubmachine)

  • fsm.get_message_queue().set_capacity(1);

    • Policy definition with Boost.Parameter

    MSM uses Boost.Parameter to allow easier definition of + common):

     fsm.get_message_queue().set_capacity(1);

    Policy definition with Boost.Parameter

    MSM uses Boost.Parameter to allow easier definition of back::state_machine<> policy arguments (all except the front-end). This allows you to define policy arguments (history, compile-time / run-time, state machine analysis, container for the queues) at any position, in any number. For example: 

     typedef msm::back::state_machine< player_,msm::back::mpl_graph_fsm_check> player;  
  typedef msm::back::state_machine< player_,msm::back::AlwaysHistory> player;  
  typedef msm::back::state_machine< player_,msm::back::mpl_graph_fsm_check,msm::back::AlwaysHistory> player; 
- typedef msm::back::state_machine< player_,msm::back::AlwaysHistory,msm::back::mpl_graph_fsm_check> player;

    Choosing when to switch active + typedef msm::back::state_machine< player_,msm::back::AlwaysHistory,msm::back::mpl_graph_fsm_check> player;

    Choosing when to switch active states

    The UML Standard is silent about a very important question: when a transition fires, at which exact point is the target state the new active state of a state machine? At the end of the transition? After the source diff --git a/doc/HTML/ch04.html b/doc/HTML/ch04.html index a0f93be..f23e9a6 100644 --- a/doc/HTML/ch04.html +++ b/doc/HTML/ch04.html @@ -1,6 +1,6 @@ - Chapter 4.  Performance / Compilers

    Chapter 4.  Performance / Compilers
    Prev Part I. User' guide Next

    Chapter 4.  Performance / Compilers

    Table of Contents

    Speed
    Executable size
    Supported compilers
    Limitations
    Compilers corner

    Tests were made on different PCs running Windows XP and Vista and compiled with + Chapter 4.  Performance / Compilers

    Chapter 4.  Performance / Compilers
    Prev Part I. User' guide Next

    Chapter 4.  Performance / Compilers

    Table of Contents

    Speed
    Executable size
    Supported compilers
    Limitations
    Compilers corner

    Tests were made on different PCs running Windows XP and Vista and compiled with VC9 SP1 or Ubuntu and compiled with g++ 4.2 and 4.3. For these tests, the same player state machine was written using Boost.Statechart, as a state machine with only simple states and as a state machine with a composite @@ -9,5 +9,5 @@ the simple one also with functors and with eUML. As these simple machines need no terminate/interrupt states, no message queue and have no-throw guarantee on their actions, the MSM state machines are defined with minimum functionality. Test machine is a Q6600 2.4GHz, Vista - 64.

    Speed

    VC9:

    • The simple test completes 90 times faster with MSM than with + 64.

      Speed

      VC9:

      • The simple test completes 90 times faster with MSM than with Boost.Statechart

      • The composite test completes 25 times faster with MSM

      gcc 4.2.3 (Ubuntu 8.04 in VMWare, same PC):

      • The simple test completes 46 times faster with MSM

      • The composite test completes 19 times faster with Msm

    Prev Up Next
    Back-end Home Executable size
    \ No newline at end of file diff --git a/doc/HTML/ch04s02.html b/doc/HTML/ch04s02.html index f1a1cd0..06c40f8 100644 --- a/doc/HTML/ch04s02.html +++ b/doc/HTML/ch04s02.html @@ -1,6 +1,6 @@ - Executable size
    Executable size
    Prev Chapter 4.  Performance / Compilers Next

    Executable size

    There are some worries that MSM generates huge code. Is it true? The 2 + Executable size

    Executable size
    Prev Chapter 4.  Performance / Compilers Next

    Executable size

    There are some worries that MSM generates huge code. Is it true? The 2 compilers I tested disagree with this claim. On VC9, the test state machines used in the performance section produce executables of 14kB (for simple and eUML) and 21kB (for the composite). This includes the test code and iostreams. diff --git a/doc/HTML/ch04s03.html b/doc/HTML/ch04s03.html index b307f8f..f02336d 100644 --- a/doc/HTML/ch04s03.html +++ b/doc/HTML/ch04s03.html @@ -1,6 +1,6 @@ - Supported compilers

    Supported compilers
    Prev Chapter 4.  Performance / Compilers Next

    Supported compilers

    For a current status, have a look at the regression tests.

    MSM was successfully tested with:

    • VC8 (partly), VC9, VC10

    • g++ 4.0.1 and higher

    • Intel 10.1 and higher

    • Clang 2.9

    • Green Hills Software MULTI for ARM v5.0.5 patch 4416 (Simple and + Supported compilers

      Supported compilers
      Prev Chapter 4.  Performance / Compilers Next

      Supported compilers

      For a current status, have a look at the regression tests.

      MSM was successfully tested with:

      • VC8 (partly), VC9, VC10

      • g++ 4.0.1 and higher

      • Intel 10.1 and higher

      • Clang 2.9

      • Green Hills Software MULTI for ARM v5.0.5 patch 4416 (Simple and Composite tutorials)

      • Partial support for IBM compiler

      VC8 and to some lesser extent VC9 suffer from a bug. Enabling the option "Enable Minimal Rebuild" (/Gm) will cause much higher compile-time (up to three times with VC8!). This option being activated per default in Debug mode, this diff --git a/doc/HTML/ch04s04.html b/doc/HTML/ch04s04.html index 6c3d009..0cad632 100644 --- a/doc/HTML/ch04s04.html +++ b/doc/HTML/ch04s04.html @@ -1,6 +1,6 @@ - Limitations

      Limitations
      Prev Chapter 4.  Performance / Compilers Next

      Limitations

      + Limitations

      Limitations
      Prev Chapter 4.  Performance / Compilers Next

      Limitations

      • Compilation times of state machines with > 80 transitions that are going to make you storm the CFO's office and make sure you get a shiny octocore with 12GB RAM by next week, unless he's interested in diff --git a/doc/HTML/ch04s05.html b/doc/HTML/ch04s05.html index da88c2f..2c2b129 100644 --- a/doc/HTML/ch04s05.html +++ b/doc/HTML/ch04s05.html @@ -1,6 +1,6 @@ - Compilers corner

        Compilers corner
        Prev Chapter 4.  Performance / Compilers Next

        Compilers corner

        Compilers are sometimes full of surprises and such strange errors happened in + Compilers corner

        Compilers corner
        Prev Chapter 4.  Performance / Compilers Next

        Compilers corner

        Compilers are sometimes full of surprises and such strange errors happened in the course of the development that I wanted to list the most fun for readers’ entertainment.

        VC8: 

        template <class StateType>
 typename ::boost::enable_if<
diff --git a/doc/HTML/ch05.html b/doc/HTML/ch05.html
index d68aa71..ff827a9 100644
--- a/doc/HTML/ch05.html
+++ b/doc/HTML/ch05.html
@@ -1,6 +1,6 @@
 
       
-   Chapter 5. Questions & Answers, tips
        Chapter 5. Questions & Answers, tips
        Prev Part I. User' guide Next
        Chapter 5. Questions & Answers, tips
        Where should I define a state machine?: The
+   Chapter 5. Questions & Answers, tips
        Chapter 5. Questions & Answers, tips
        Prev Part I. User' guide Next
        Chapter 5. Questions & Answers, tips
        Where should I define a state machine?: The
                 tutorials are implemented in a simple cpp source file for simplicity. I want to
                 model dynamic behavior of a class as a state machine, how should I define the state
                 machine?
        Answer: Usually you'll want to implement the
diff --git a/doc/HTML/ch06.html b/doc/HTML/ch06.html
index 9f9506e..64f1bd3 100644
--- a/doc/HTML/ch06.html
+++ b/doc/HTML/ch06.html
@@ -1,9 +1,9 @@
 
       
-   Chapter 6. Internals
        Chapter 6. Internals
        Prev Part I. User' guide Next
        Chapter 6. Internals
        Table of Contents
        Backend: Run To Completion
        Frontend / Backend
+   Chapter 6. Internals
        Chapter 6. Internals
        Prev Part I. User' guide Next
        Chapter 6. Internals
        Table of Contents
        Backend: Run To Completion
        Frontend / Backend
                     interface
         Generated state ids 
        Metaprogramming tools
        This chapter describes the internal machinery of the back-end, which can be useful
                 for UML experts but can be safely ignored for most users. For implementers, the
-                interface between front- and back- end is also described in detail.
        Backend: Run To Completion
        The back-end implements the following run-to completion algorithm:
        • Check if one region of the concrete state machine is in a
+                interface between front- and back- end is also described in detail.
          Backend: Run To Completion
          The back-end implements the following run-to completion algorithm:
          • Check if one region of the concrete state machine is in a
                                 terminate or interrupt state. If yes, event processing is disabled
                                 while the condition lasts (forever for a terminate pseudo-state,
                                 while active for an interrupt pseudo-state).
          • If the message queue feature is enabled and if the state machine
diff --git a/doc/HTML/ch06s02.html b/doc/HTML/ch06s02.html
index 605c758..b6edd86 100644
--- a/doc/HTML/ch06s02.html
+++ b/doc/HTML/ch06s02.html
@@ -1,7 +1,7 @@
 
       
-   Frontend / Backend interface
            Frontend / Backend
-                    interface
            Prev Chapter 6. Internals Next
            Frontend / Backend
+   Frontend / Backend interface
            Frontend / Backend
+                    interface
            Prev Chapter 6. Internals Next
            Frontend / Backend
                     interface
            The design of MSM tries to make front-ends and back-ends (later) to be as
                     interchangeable as possible. Of course, no back-end will ever implement every
                     feature defined by any possible front-end and inversely, but the goal is to make
diff --git a/doc/HTML/ch06s03.html b/doc/HTML/ch06s03.html
index 7c1a611..a30dc32 100644
--- a/doc/HTML/ch06s03.html
+++ b/doc/HTML/ch06s03.html
@@ -1,6 +1,6 @@
 
       
-   Generated state ids
             Generated state ids 
            Prev Chapter 6. Internals Next
             Generated state ids 
            Normally, one does not need to know the ids are generated for all the states
+   Generated state ids
             Generated state ids 
            Prev Chapter 6. Internals Next
             Generated state ids 
            Normally, one does not need to know the ids are generated for all the states
                     of a state machine, unless for debugging purposes, like the pstate function does
                     in the tutorials in order to display the name of the current state. This section
                     will show how to automatically display typeid-generated names, but these are not
diff --git a/doc/HTML/ch06s04.html b/doc/HTML/ch06s04.html
index a170d33..24b8efd 100644
--- a/doc/HTML/ch06s04.html
+++ b/doc/HTML/ch06s04.html
@@ -1,6 +1,6 @@
 
       
-   Metaprogramming tools
            Metaprogramming tools
            Prev Chapter 6. Internals Next
            Metaprogramming tools
            We can find for the transition table more uses than what we have seen so far.
+   Metaprogramming tools
            Metaprogramming tools
            Prev Chapter 6. Internals Next
            Metaprogramming tools
            We can find for the transition table more uses than what we have seen so far.
                     Let's suppose you need to write a coverage tool. A state machine would be
                     perfect for such a job, if only it could provide some information about its
                     structure. Thanks to the transition table and Boost.MPL, it does.
            What is needed for a coverage tool? You need to know how many states are
diff --git a/doc/HTML/ch07.html b/doc/HTML/ch07.html
index 306e090..a01e3a0 100644
--- a/doc/HTML/ch07.html
+++ b/doc/HTML/ch07.html
@@ -1,6 +1,6 @@
 
       
-   Chapter 7. Acknowledgements
            Chapter 7. Acknowledgements
            Prev Part I. User' guide Next
            Chapter 7. Acknowledgements
            Table of Contents
            MSM v2
             MSM v1
            I am in debt to the following people who helped MSM along the way.
            MSM v2
            
+   Chapter 7. Acknowledgements
            Chapter 7. Acknowledgements
            Prev Part I. User' guide Next
            Chapter 7. Acknowledgements
            Table of Contents
            MSM v2
             MSM v1
            I am in debt to the following people who helped MSM along the way.
            MSM v2
            
                     
            • Thanks to Dave Abrahams for managing the review
            • Thanks to Eric Niebler for his patience correcting my grammar
                                 errors
            • Special thanks to Joel de Guzman who gave me very good ideas at
                                 the BoostCon09. These ideas were the starting point of the redesign.
diff --git a/doc/HTML/ch07s02.html b/doc/HTML/ch07s02.html
index 6e0b1c6..0b60d06 100644
--- a/doc/HTML/ch07s02.html
+++ b/doc/HTML/ch07s02.html
@@ -1,6 +1,6 @@
 
       
-   MSM v1
               MSM v1
              Prev Chapter 7. Acknowledgements Next
               MSM v1
              
+   MSM v1
               MSM v1
              Prev Chapter 7. Acknowledgements Next
               MSM v1
              
                     
              • The original version of this framework is based on the brilliant
                                 work of David Abrahams and Aleksey Gurtovoy who laid down the base
                                 and the principles of the framework in their excellent book, “C++
diff --git a/doc/HTML/ch08.html b/doc/HTML/ch08.html
index 0e3e33d..272535f 100644
--- a/doc/HTML/ch08.html
+++ b/doc/HTML/ch08.html
@@ -1,21 +1,11 @@
 
       
-   Chapter 8. Version history
                Chapter 8. Version history
                Prev Part I. User' guide Next
                Chapter 8. Version history
                Table of Contents
                From V2.21 to V2.22 (Boost 1.48)
                From V2.20 to V2.21 (Boost 1.47)
                From V2.12 to V2.20 (Boost 1.46)
                From V2.10 to V2.12  (Boost 1.45)
                From V2.0 to V2.12  (Boost 1.44)
                From V2.21 to V2.22 (Boost 1.48)
                
-                    
                • eUML: added easier event reprocessing:
-                                    process(event_) and reprocess()
                • Rewrite of internal transition tables. There were a few bugs
-                                (failing recursivity in internal transition tables of sub-sub
-                                machines) and a missing feature (unused internal transition table of
-                                the main state machine).
                • Bugfixes
                  • Reverted favor_compile_time policy to Boost 1.46
-                                            state
                  • none event now is convertible from any
-                                            other event 
                  • eUML and pseudo exit states
                  • Fixed not working Flag_AND
                  • Fixed rare bugs causing multiple processing of the
-                                            same event in a submachine whose transition table
-                                            contains this event and a base event of it.
                  • gcc warnings about unused variables
                • Breaking change: the new internal transition table feature causes
-                                a minor breaking change. In a submachine, the "Fsm" template
-                                parameter for guards / actions of an internal table declared using
-                                    internal_transition_table now is the submachine,
-                                not the higher-level state machine. Internal transitions declared
-                                using internal rows in the higher-level state machine keep their
-                                behavior (the "Fsm" parameter is the higher-level state machine). To
-                                sum up, the internal transition "Fsm" parameter is the closest state
-                                machine containing this transition.
                
-                
                Prev Up Next
                 MSM v1 Home From V2.20 to V2.21 (Boost 1.47)
                
\ No newline at end of file
+   Chapter 8. Version history
                Chapter 8. Version history
                Prev Part I. User' guide Next
                Chapter 8. Version history
                Table of Contents
                From V2.22 to V2.23 (Boost 1.50)
                From V2.21 to V2.22 (Boost 1.48)
                From V2.20 to V2.21 (Boost 1.47)
                From V2.12 to V2.20 (Boost 1.46)
                From V2.10 to V2.12  (Boost 1.45)
                From V2.0 to V2.12  (Boost 1.44)
                From V2.22 to V2.23 (Boost 1.50)
                
+                    
                •  eUML : better syntax
+                                for front-ends defined with eUML as transititon table only. Caution:
+                                Breaking Change!
                • Bugfix: graph building was only working if
+                                    initial_state defined as a sequence
                • Bugfix: flags defined for a Terminate or Interrupt state do not
+                                break the blocking function of these states any more.
                • Bugfix: multiple deferred events from several regions were not
+                                working in every case.
                • Bugfix: visitor was passed by value to submachines.
                • Bugfix: no_transition was not called for submachines who send an
+                                event to themselves.
                • Fixed warnings with gcc
                
+                
                Prev Up Next
                 MSM v1 Home From V2.21 to V2.22 (Boost 1.48)
                
\ No newline at end of file
diff --git a/doc/HTML/ch08s02.html b/doc/HTML/ch08s02.html
index 75ea5bc..b506a0c 100644
--- a/doc/HTML/ch08s02.html
+++ b/doc/HTML/ch08s02.html
@@ -1,10 +1,21 @@
 
       
-   From V2.20 to V2.21 (Boost 1.47)
                From V2.20 to V2.21 (Boost 1.47)
                Prev Chapter 8. Version history Next
                From V2.20 to V2.21 (Boost 1.47)
                
-                    
                • Added a stop()
-                                method in the back-end.
                • Added partial support for
-                                Boost.Phoenix functors in eUML
                • Added the possibility to choose when state switching
-                                occurs.
                • Bugfixes
                  • Trac 5117, 5253, 5533, 5573
                  • gcc warnings about unused variables
                  • better implemenation of favor_compile_time back-end
-                                        policy
                  • bug with eUML and state construction
                  • incorrect eUML event and state macros
                  • incorrect event type passed to a direct entry state's
-                                        on_entry action
                  • more examples
                
-                
                Prev Up Next
                Chapter 8. Version history Home From V2.12 to V2.20 (Boost 1.46)
                
\ No newline at end of file
+   From V2.21 to V2.22 (Boost 1.48)
                From V2.21 to V2.22 (Boost 1.48)
                Prev Chapter 8. Version history Next
                From V2.21 to V2.22 (Boost 1.48)
                
+                    
                • eUML: added easier event reprocessing:
+                                    process(event_) and reprocess()
                • Rewrite of internal transition tables. There were a few bugs
+                                (failing recursivity in internal transition tables of sub-sub
+                                machines) and a missing feature (unused internal transition table of
+                                the main state machine).
                • Bugfixes
                  • Reverted favor_compile_time policy to Boost 1.46
+                                            state
                  • none event now is convertible from any
+                                            other event 
                  • eUML and pseudo exit states
                  • Fixed not working Flag_AND
                  • Fixed rare bugs causing multiple processing of the
+                                            same event in a submachine whose transition table
+                                            contains this event and a base event of it.
                  • gcc warnings about unused variables
                • Breaking change: the new internal transition table feature causes
+                                a minor breaking change. In a submachine, the "Fsm" template
+                                parameter for guards / actions of an internal table declared using
+                                    internal_transition_table now is the submachine,
+                                not the higher-level state machine. Internal transitions declared
+                                using internal rows in the higher-level state machine keep their
+                                behavior (the "Fsm" parameter is the higher-level state machine). To
+                                sum up, the internal transition "Fsm" parameter is the closest state
+                                machine containing this transition.
                
+                
                Prev Up Next
                Chapter 8. Version history Home From V2.20 to V2.21 (Boost 1.47)
                
\ No newline at end of file
diff --git a/doc/HTML/ch08s03.html b/doc/HTML/ch08s03.html
index fa6e199..bafda02 100644
--- a/doc/HTML/ch08s03.html
+++ b/doc/HTML/ch08s03.html
@@ -1,12 +1,10 @@
 
       
-   From V2.12 to V2.20 (Boost 1.46)
                From V2.12 to V2.20 (Boost 1.46)
                Prev Chapter 8. Version history Next
                From V2.12 to V2.20 (Boost 1.46)
                
-                    
                
-                
                Prev Up Next
                From V2.20 to V2.21 (Boost 1.47) Home From V2.10 to V2.12  (Boost 1.45)
                
\ No newline at end of file
+   From V2.20 to V2.21 (Boost 1.47)
                From V2.20 to V2.21 (Boost 1.47)
                Prev Chapter 8. Version history Next
                From V2.20 to V2.21 (Boost 1.47)
                
+                    
                • Added a stop()
+                                method in the back-end.
                • Added partial support for
+                                Boost.Phoenix functors in eUML
                • Added the possibility to choose when state switching
+                                occurs.
                • Bugfixes
                  • Trac 5117, 5253, 5533, 5573
                  • gcc warnings about unused variables
                  • better implemenation of favor_compile_time back-end
+                                        policy
                  • bug with eUML and state construction
                  • incorrect eUML event and state macros
                  • incorrect event type passed to a direct entry state's
+                                        on_entry action
                  • more examples
                
+                
                Prev Up Next
                From V2.21 to V2.22 (Boost 1.48) Home From V2.12 to V2.20 (Boost 1.46)
                
\ No newline at end of file
diff --git a/doc/HTML/ch08s04.html b/doc/HTML/ch08s04.html
index 9a0bf6a..86dbd00 100644
--- a/doc/HTML/ch08s04.html
+++ b/doc/HTML/ch08s04.html
@@ -1,9 +1,12 @@
 
       
-   From V2.10 to V2.12 (Boost 1.45)
                From V2.10 to V2.12  (Boost 1.45)
                Prev Chapter 8. Version history Next
                From V2.10 to V2.12  (Boost 1.45)
                
-                    
                
-                
                Prev Up Next
                From V2.12 to V2.20 (Boost 1.46) Home From V2.0 to V2.12  (Boost 1.44)
                
\ No newline at end of file
+   From V2.12 to V2.20 (Boost 1.46)
                From V2.12 to V2.20 (Boost 1.46)
                Prev Chapter 8. Version history Next
                From V2.12 to V2.20 (Boost 1.46)
                
+                    
                
+                
                Prev Up Next
                From V2.20 to V2.21 (Boost 1.47) Home From V2.10 to V2.12  (Boost 1.45)
                
\ No newline at end of file
diff --git a/doc/HTML/ch08s05.html b/doc/HTML/ch08s05.html
index b8bec66..f5ec4d7 100644
--- a/doc/HTML/ch08s05.html
+++ b/doc/HTML/ch08s05.html
@@ -1,9 +1,9 @@
 
       
-   From V2.0 to V2.12 (Boost 1.44)
                From V2.0 to V2.12  (Boost 1.44)
                Prev Chapter 8. Version history Next
                From V2.0 to V2.12  (Boost 1.44)
                
-                    
                • New documentation
                • Internal transitions. Either as part of the transition table or
-                                using a state's internal transition table
                • increased dispatch and copy speed
                • new row types for the
-                                basic front-end
                • new eUML syntax, better attribute support, macros to ease
-                                developer's life. Even VC8 seems to like it better.
                • New policy for reduced compile-time at the cost of dispatch
-                                speed
                • Support for base events
                • possibility to choose the initial event
                
-                
                Prev Up Next
                From V2.10 to V2.12  (Boost 1.45) Home Part II. Reference
                
\ No newline at end of file
+   From V2.10 to V2.12 (Boost 1.45)
                From V2.10 to V2.12  (Boost 1.45)
                Prev Chapter 8. Version history Next
                From V2.10 to V2.12  (Boost 1.45)
                
+                    
                
+                
                Prev Up Next
                From V2.12 to V2.20 (Boost 1.46) Home From V2.0 to V2.12  (Boost 1.44)
                
\ No newline at end of file
diff --git a/doc/HTML/ch08s06.html b/doc/HTML/ch08s06.html
new file mode 100644
index 0000000..b31ce9f
--- /dev/null
+++ b/doc/HTML/ch08s06.html
@@ -0,0 +1,9 @@
+
+      
+   From V2.0 to V2.12 (Boost 1.44)
                From V2.0 to V2.12  (Boost 1.44)
                Prev Chapter 8. Version history Next
                From V2.0 to V2.12  (Boost 1.44)
                
+                    
                • New documentation
                • Internal transitions. Either as part of the transition table or
+                                using a state's internal transition table
                • increased dispatch and copy speed
                • new row types for the
+                                basic front-end
                • new eUML syntax, better attribute support, macros to ease
+                                developer's life. Even VC8 seems to like it better.
                • New policy for reduced compile-time at the cost of dispatch
+                                speed
                • Support for base events
                • possibility to choose the initial event
                
+                
                Prev Up Next
                From V2.10 to V2.12  (Boost 1.45) Home Part II. Reference
                
\ No newline at end of file
diff --git a/doc/HTML/ch09.html b/doc/HTML/ch09.html
index 9804ddb..1979725 100644
--- a/doc/HTML/ch09.html
+++ b/doc/HTML/ch09.html
@@ -1,7 +1,7 @@
 
       
-   Chapter 9. eUML operators and basic helpers
                Chapter 9. eUML operators and basic helpers
                Prev Part II. Reference Next
                Chapter 9. eUML operators and basic helpers
                The following table lists the supported operators: 
                
-                
                Table 9.1. Operators and state machine helpers
                eUML function / operatorDescriptionFunctor
                &&Calls lazily Action1&& Action2And_
                ||Calls lazily Action1|| Action2Or_
                !Calls lazily !Action1Not_
                !=Calls lazily Action1 != Action2NotEqualTo_
                ==Calls lazily Action1 == Action2EqualTo_
                >Calls lazily Action1 > Action2Greater_
                >=Calls lazily Action1 >= Action2Greater_Equal_
                <Calls lazily Action1 < Action2Less_
                <=Calls lazily Action1 <= Action2Less_Equal_
                &Calls lazily Action1 & Action2Bitwise_And_
                |Calls lazily Action1 | Action2Bitwise_Or_
                ^Calls lazily Action1 ^ Action2Bitwise_Xor_
                --Calls lazily --Action1 / Action1--Pre_Dec_ / Post_Dec_
                ++Calls lazily ++Action1 / Action1++Pre_Inc_ / Post_Inc_
                /Calls lazily Action1 / Action2Divides_
                /=Calls lazily Action1 /= Action2Divides_Assign_
                *Calls lazily Action1 * Action2Multiplies_
                *=Calls lazily Action1 *= Action2Multiplies_Assign_
                + (binary)Calls lazily Action1 + Action2Plus_
                + (unary)Calls lazily +Action1Unary_Plus_
                +=Calls lazily Action1 += Action2Plus_Assign_
                - (binary)Calls lazily Action1 - Action2Minus_
                - (unary)Calls lazily -Action1Unary_Minus_
                -=Calls lazily Action1 -= Action2Minus_Assign_
                %Calls lazily Action1 % Action2Modulus_
                %=Calls lazily Action1 %= Action2Modulus_Assign_
                >>Calls lazily Action1 >> Action2ShiftRight_
                >>=Calls lazily Action1 >>= Action2ShiftRight_Assign_
                <<Calls lazily Action1 << Action2ShiftLeft_
                <<=Calls lazily Action1 <<= Action2ShiftLeft_Assign_
                [] (works on vector, map, arrays)Calls lazily Action1 [Action2]Subscript_
                if_then_else_(Condition,Action1,Action2)Returns either the result of calling Action1 or the result of
+   Chapter 9. eUML operators and basic helpers
                Chapter 9. eUML operators and basic helpers
                Prev Part II. Reference Next
                Chapter 9. eUML operators and basic helpers
                The following table lists the supported operators: 
                
+                
                Table 9.1. Operators and state machine helpers
                eUML function / operatorDescriptionFunctor
                &&Calls lazily Action1&& Action2And_
                ||Calls lazily Action1|| Action2Or_
                !Calls lazily !Action1Not_
                !=Calls lazily Action1 != Action2NotEqualTo_
                ==Calls lazily Action1 == Action2EqualTo_
                >Calls lazily Action1 > Action2Greater_
                >=Calls lazily Action1 >= Action2Greater_Equal_
                <Calls lazily Action1 < Action2Less_
                <=Calls lazily Action1 <= Action2Less_Equal_
                &Calls lazily Action1 & Action2Bitwise_And_
                |Calls lazily Action1 | Action2Bitwise_Or_
                ^Calls lazily Action1 ^ Action2Bitwise_Xor_
                --Calls lazily --Action1 / Action1--Pre_Dec_ / Post_Dec_
                ++Calls lazily ++Action1 / Action1++Pre_Inc_ / Post_Inc_
                /Calls lazily Action1 / Action2Divides_
                /=Calls lazily Action1 /= Action2Divides_Assign_
                *Calls lazily Action1 * Action2Multiplies_
                *=Calls lazily Action1 *= Action2Multiplies_Assign_
                + (binary)Calls lazily Action1 + Action2Plus_
                + (unary)Calls lazily +Action1Unary_Plus_
                +=Calls lazily Action1 += Action2Plus_Assign_
                - (binary)Calls lazily Action1 - Action2Minus_
                - (unary)Calls lazily -Action1Unary_Minus_
                -=Calls lazily Action1 -= Action2Minus_Assign_
                %Calls lazily Action1 % Action2Modulus_
                %=Calls lazily Action1 %= Action2Modulus_Assign_
                >>Calls lazily Action1 >> Action2ShiftRight_
                >>=Calls lazily Action1 >>= Action2ShiftRight_Assign_
                <<Calls lazily Action1 << Action2ShiftLeft_
                <<=Calls lazily Action1 <<= Action2ShiftLeft_Assign_
                [] (works on vector, map, arrays)Calls lazily Action1 [Action2]Subscript_
                if_then_else_(Condition,Action1,Action2)Returns either the result of calling Action1 or the result of
                                     calling Action2If_Else_
                if_then_(Condition,Action)Returns the result of calling Action if ConditionIf_Then_
                while_(Condition, Body)While Condition(), calls Body(). Returns nothingWhile_Do_
                do_while_(Condition, Body)Calls Body() while Condition(). Returns nothingDo_While_
                for_(Begin,Stop,EndLoop,Body)Calls for(Begin;Stop;EndLoop){Body;}For_Loop_
                process_(Event [,fsm1] [,fsm2] [,fsm3] [,fsm4])Processes Event on the current state machine (if no fsm
                                     specified) or on up to 4 state machines returned by an
                                     appropriate functor.Process_
                process2_(Event, Data [,fsm1] [,fsm2] [,fsm3])Processes Event on the current state machine (if no fsm
diff --git a/doc/HTML/ch10.html b/doc/HTML/ch10.html
index 2b93d5f..8302519 100644
--- a/doc/HTML/ch10.html
+++ b/doc/HTML/ch10.html
@@ -1,33 +1,33 @@
 
       
-   Chapter 10.  Functional programming
                Chapter 10. 
-                Functional programming 
                Prev Part II. Reference Next
                Chapter 10. 
+   Chapter 10.  Functional programming
                Chapter 10. 
+                Functional programming 
                Prev Part II. Reference Next
                Chapter 10. 
                 Functional programming 
                To use these functions, you need to include: 
                #include <msm/front/euml/stl.hpp>
                or the specified header in the following tables.
                The following tables list the supported STL algorithms: 
                
                 
-                
                Table 10.1. STL algorithms
                STL algorithms in querying.hppFunctor
                find_(first, last, value)Find_
                find_if_(first, last, value)FindIf_
                lower_bound_(first, last, value [,opᵃ])LowerBound_
                upper_bound_(first, last, value [,opᵃ])UpperBound_
                equal_range_(first, last, value [,opᵃ])EqualRange_
                binary_search_(first, last, value [,opᵃ])BinarySearch_
                min_element_(first, last[,opᵃ])MinElement_
                max_element_(first, last[,opᵃ])MaxElement_
                adjacent_find_(first, last[,opᵃ])AdjacentFind_
                find_end_( first1, last1, first2, last2 [,op ᵃ])FindEnd_
                find_first_of_( first1, last1, first2, last2 [,op ᵃ])FindFirstOf_
                equal_( first1, last1, first2 [,op ᵃ])Equal_
                search_( first1, last1, first2, last2 [,op ᵃ])Search_
                includes_( first1, last1, first2, last2 [,op ᵃ])Includes_
                lexicographical_compare_ ( first1, last1, first2, last2 [,op
+                
                Table 10.1. STL algorithms
                STL algorithms in querying.hppFunctor
                find_(first, last, value)Find_
                find_if_(first, last, value)FindIf_
                lower_bound_(first, last, value [,opᵃ])LowerBound_
                upper_bound_(first, last, value [,opᵃ])UpperBound_
                equal_range_(first, last, value [,opᵃ])EqualRange_
                binary_search_(first, last, value [,opᵃ])BinarySearch_
                min_element_(first, last[,opᵃ])MinElement_
                max_element_(first, last[,opᵃ])MaxElement_
                adjacent_find_(first, last[,opᵃ])AdjacentFind_
                find_end_( first1, last1, first2, last2 [,op ᵃ])FindEnd_
                find_first_of_( first1, last1, first2, last2 [,op ᵃ])FindFirstOf_
                equal_( first1, last1, first2 [,op ᵃ])Equal_
                search_( first1, last1, first2, last2 [,op ᵃ])Search_
                includes_( first1, last1, first2, last2 [,op ᵃ])Includes_
                lexicographical_compare_ ( first1, last1, first2, last2 [,op
                                     ᵃ]) LexicographicalCompare_
                count_(first, last, value [,size])Count_
                count_if_(first, last, op ᵃ [,size])CountIf_
                distance_(first, last)Distance_
                mismatch _( first1, last1, first2 [,op ᵃ])Mismatch_

                
             
                
                 
-                
                Table 10.2. STL algorithms
                STL algorithms in iteration.hppFunctor
                for_each_(first,last, unary opᵃ)ForEach_
                accumulate_first, last, init [,opᵃ])Accumulate_

                
+                
                Table 10.2. STL algorithms
                STL algorithms in iteration.hppFunctor
                for_each_(first,last, unary opᵃ)ForEach_
                accumulate_first, last, init [,opᵃ])Accumulate_

                
             
                
                 
-                
                Table 10.3. STL algorithms
                STL algorithms in transformation.hppFunctor
                copy_(first, last, result)Copy_
                copy_backward_(first, last, result)CopyBackward_
                reverse_(first, last)Reverse_
                reverse_copy_(first, last , result)ReverseCopy_
                remove_(first, last, value)Remove_
                remove_if_(first, last , opᵃ)RemoveIf_
                remove_copy_(first, last , output, value)RemoveCopy_
                remove_copy_if_(first, last, output, opᵃ)RemoveCopyIf_
                fill_(first, last, value)Fill_
                fill_n_(first, size, value)ᵇFillN_
                generate_(first, last, generatorᵃ)Generate_
                generate_(first, size, generatorᵃ)ᵇGenerateN_
                unique_(first, last [,opᵃ])Unique_
                unique_copy_(first, last, output [,opᵃ])UniqueCopy_
                random_shuffle_(first, last [,opᵃ])RandomShuffle_
                rotate_copy_(first, middle, last, output)RotateCopy_
                partition_ (first, last [,opᵃ])Partition_
                stable_partition_ (first, last [,opᵃ])StablePartition_
                stable_sort_(first, last [,opᵃ])StableSort_
                sort_(first, last [,opᵃ])Sort_
                partial_sort_(first, middle, last [,opᵃ])PartialSort_
                partial_sort_copy_ (first, last, res_first, res_last [,opᵃ]) PartialSortCopy_
                nth_element_(first, nth, last [,opᵃ])NthElement_
                merge_( first1, last1, first2, last2, output [,op ᵃ])Merge_
                inplace_merge_(first, middle, last [,opᵃ])InplaceMerge_
                set_union_(first1, last1, first2, last2, output [,op
+                
                Table 10.3. STL algorithms
                STL algorithms in transformation.hppFunctor
                copy_(first, last, result)Copy_
                copy_backward_(first, last, result)CopyBackward_
                reverse_(first, last)Reverse_
                reverse_copy_(first, last , result)ReverseCopy_
                remove_(first, last, value)Remove_
                remove_if_(first, last , opᵃ)RemoveIf_
                remove_copy_(first, last , output, value)RemoveCopy_
                remove_copy_if_(first, last, output, opᵃ)RemoveCopyIf_
                fill_(first, last, value)Fill_
                fill_n_(first, size, value)ᵇFillN_
                generate_(first, last, generatorᵃ)Generate_
                generate_(first, size, generatorᵃ)ᵇGenerateN_
                unique_(first, last [,opᵃ])Unique_
                unique_copy_(first, last, output [,opᵃ])UniqueCopy_
                random_shuffle_(first, last [,opᵃ])RandomShuffle_
                rotate_copy_(first, middle, last, output)RotateCopy_
                partition_ (first, last [,opᵃ])Partition_
                stable_partition_ (first, last [,opᵃ])StablePartition_
                stable_sort_(first, last [,opᵃ])StableSort_
                sort_(first, last [,opᵃ])Sort_
                partial_sort_(first, middle, last [,opᵃ])PartialSort_
                partial_sort_copy_ (first, last, res_first, res_last [,opᵃ]) PartialSortCopy_
                nth_element_(first, nth, last [,opᵃ])NthElement_
                merge_( first1, last1, first2, last2, output [,op ᵃ])Merge_
                inplace_merge_(first, middle, last [,opᵃ])InplaceMerge_
                set_union_(first1, last1, first2, last2, output [,op
                                     ᵃ])SetUnion_
                push_heap_(first, last [,op ᵃ])PushHeap_
                pop_heap_(first, last [,op ᵃ])PopHeap_
                make_heap_(first, last [,op ᵃ])MakeHeap_
                sort_heap_(first, last [,op ᵃ])SortHeap_
                next_permutation_(first, last [,op ᵃ])NextPermutation_
                prev_permutation_(first, last [,op ᵃ])PrevPermutation_
                inner_product_(first1, last1, first2, init [,op1ᵃ] [,op2ᵃ]) InnerProduct_
                partial_sum_(first, last, output [,opᵃ])PartialSum_
                adjacent_difference_(first, last, output [,opᵃ])AdjacentDifference_
                replace_(first, last, old_value, new_value)Replace_
                replace_if_(first, last, opᵃ, new_value)ReplaceIf_
                replace_copy_(first, last, result, old_value,
                                     new_value)ReplaceCopy_
                replace_copy_if_(first, last, result, opᵃ, new_value)ReplaceCopyIf_
                rotate_(first, middle, last)ᵇRotate_

                
             
                
                 
-                
                Table 10.4. STL container methods
                STL container methods(common) in container.hppFunctor
                container::reference front_(container)Front_
                container::reference back_(container)Back_
                container::iterator begin_(container)Begin_
                container::iterator end_(container)End_
                container::reverse_iterator rbegin_(container)RBegin_
                container::reverse_iterator rend_(container)REnd_
                void push_back_(container, value)Push_Back_
                void pop_back_(container, value)Pop_Back_
                void push_front_(container, value)Push_Front_
                void pop_front_(container, value)Pop_Front_
                void clear_(container)Clear_
                size_type capacity_(container)Capacity_
                size_type size_(container)Size_
                size_type max_size_(container)Max_Size_
                void reserve_(container, value)Reserve _
                void resize_(container, value)Resize _
                iterator insert_(container, pos, value)Insert_
                void insert_( container , pos, first, last)Insert_
                void insert_( container , pos, number, value)Insert_
                void swap_( container , other_container)Swap_
                void erase_( container , pos)Erase_
                void erase_( container , first, last) Erase_
                bool empty_( container)Empty_

                
+                
                Table 10.4. STL container methods
                STL container methods(common) in container.hppFunctor
                container::reference front_(container)Front_
                container::reference back_(container)Back_
                container::iterator begin_(container)Begin_
                container::iterator end_(container)End_
                container::reverse_iterator rbegin_(container)RBegin_
                container::reverse_iterator rend_(container)REnd_
                void push_back_(container, value)Push_Back_
                void pop_back_(container, value)Pop_Back_
                void push_front_(container, value)Push_Front_
                void pop_front_(container, value)Pop_Front_
                void clear_(container)Clear_
                size_type capacity_(container)Capacity_
                size_type size_(container)Size_
                size_type max_size_(container)Max_Size_
                void reserve_(container, value)Reserve _
                void resize_(container, value)Resize _
                iterator insert_(container, pos, value)Insert_
                void insert_( container , pos, first, last)Insert_
                void insert_( container , pos, number, value)Insert_
                void swap_( container , other_container)Swap_
                void erase_( container , pos)Erase_
                void erase_( container , first, last) Erase_
                bool empty_( container)Empty_

                
             
                
-                
                Table 10.5. STL list methods
                std::list methods in container.hppFunctor
                void list_remove_(container, value)ListRemove_
                void list_remove_if_(container, opᵃ)ListRemove_If_
                void list_merge_(container, other_list)ListMerge_
                void list_merge_(container, other_list, opᵃ)ListMerge_
                void splice_(container, iterator, other_list)Splice_
                void splice_(container, iterator, other_list,
+                
                Table 10.5. STL list methods
                std::list methods in container.hppFunctor
                void list_remove_(container, value)ListRemove_
                void list_remove_if_(container, opᵃ)ListRemove_If_
                void list_merge_(container, other_list)ListMerge_
                void list_merge_(container, other_list, opᵃ)ListMerge_
                void splice_(container, iterator, other_list)Splice_
                void splice_(container, iterator, other_list,
                                     iterator)Splice_
                void splice_(container, iterator, other_list, first,
                                     last)Splice_
                void list_reverse_(container)ListReverse_
                void list_unique_(container)ListUnique_
                void list_unique_(container, opᵃ)ListUnique_
                void list_sort_(container)ListSort_
                void list_sort_(container, opᵃ)ListSort_

                
             
                
-                
                Table 10.6. STL associative container methods 
                Associative container methods in container.hppFunctor
                iterator insert_(container, pos, value)Insert_
                void insert_( container , first, last)Insert_
                pair<iterator, bool> insert_( container , value)Insert_
                void associative_erase_( container , pos)Associative_Erase_
                void associative_erase_( container , first, last)Associative_Erase_
                size_type associative_erase_( container , key)Associative_Erase_
                iterator associative_find_( container , key)Associative_Find_
                size_type associative_count_( container , key)AssociativeCount_
                iterator associative_lower_bound_( container , key)Associative_Lower_Bound_
                iterator associative_upper_bound_( container , key)Associative_Upper_Bound_
                pair<iterator, iterator> associative_equal_range_(
+                
                Table 10.6. STL associative container methods 
                Associative container methods in container.hppFunctor
                iterator insert_(container, pos, value)Insert_
                void insert_( container , first, last)Insert_
                pair<iterator, bool> insert_( container , value)Insert_
                void associative_erase_( container , pos)Associative_Erase_
                void associative_erase_( container , first, last)Associative_Erase_
                size_type associative_erase_( container , key)Associative_Erase_
                iterator associative_find_( container , key)Associative_Find_
                size_type associative_count_( container , key)AssociativeCount_
                iterator associative_lower_bound_( container , key)Associative_Lower_Bound_
                iterator associative_upper_bound_( container , key)Associative_Upper_Bound_
                pair<iterator, iterator> associative_equal_range_(
                                     container , key)Associative_Equal_Range_

                
             
                
-                
                Table 10.7. STL pair
                std::pair in container.hppFunctor
                first_type first_(pair<T1, T2>)First_
                second_type second_(pair<T1, T2>)Second_

                
+                
                Table 10.7. STL pair
                std::pair in container.hppFunctor
                first_type first_(pair<T1, T2>)First_
                second_type second_(pair<T1, T2>)Second_

                
             
                
-                
                Table 10.8. STL string
                STL string methodstd::string method in container.hppFunctor
                substr (size_type pos, size_type size)string substr_(container, pos, length)Substr_
                int compare(string)int string_compare_(container, another_string)StringCompare_
                int compare(char*)int string_compare_(container, another_string)StringCompare_
                int compare(size_type pos, size_type size, string)int string_compare_(container, pos, size,
+                
                Table 10.8. STL string
                STL string methodstd::string method in container.hppFunctor
                substr (size_type pos, size_type size)string substr_(container, pos, length)Substr_
                int compare(string)int string_compare_(container, another_string)StringCompare_
                int compare(char*)int string_compare_(container, another_string)StringCompare_
                int compare(size_type pos, size_type size, string)int string_compare_(container, pos, size,
                                     another_string)StringCompare_
                int compare (size_type pos, size_type size, string, size_type
                                     length)int string_compare_(container, pos, size, another_string,
                                     length)StringCompare_
                string& append(const string&)string& append_(container, another_string)Append_
                string& append (charT*)string& append_(container, another_string)Append_
                string& append (string , size_type pos, size_type
diff --git a/doc/HTML/examples/CompositeTutorialWithEumlTable.cpp b/doc/HTML/examples/CompositeTutorialWithEumlTable.cpp
index 7783d2c..7fce5de 100644
--- a/doc/HTML/examples/CompositeTutorialWithEumlTable.cpp
+++ b/doc/HTML/examples/CompositeTutorialWithEumlTable.cpp
@@ -112,11 +112,7 @@ namespace
 
     };
     // Playing Submachine back-end
-    typedef boost::msm::back::state_machine Playing_helper;
-    struct Playing_impl : public Playing_helper,
-                          public msm::front::euml::euml_state
-    {
-    };
+    typedef boost::msm::back::state_machine Playing_impl;
 
     // state not defining any entry or exit
     struct Paused_impl : public msm::front::state<> , public msm::front::euml::euml_state
diff --git a/doc/HTML/index.html b/doc/HTML/index.html
index 1dae2be..7109fd3 100644
--- a/doc/HTML/index.html
+++ b/doc/HTML/index.html
@@ -1,19 +1,19 @@
 
       
-   Meta State Machine (MSM)
                Meta State Machine (MSM)
                   Next
                Meta State Machine (MSM)
                Copyright © 2008-2010 
+   Meta State Machine (MSM)
                Meta State Machine (MSM)
                   Next
                Meta State Machine (MSM)
                Copyright © 2008-2010 
                  Distributed under the Boost Software License, Version 1.0. (See
                     accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt ) 
             
                Table of Contents
                Preface
                I. User' guide
                1. Founding idea
                2. UML Short Guide
                What are state machines?
                Concepts
                State machine, state, transition, event 
                Submachines, orthogonal regions, pseudostates 
                
                         History 
                Completion transitions / anonymous
                         transitions
                 Internal transitions 
                
                         Conflicting transitions 
                State machine glossary
                3. Tutorial
                Design
                Basic front-end
                A simple example
                Transition table
                Defining states with entry/exit actions
                What do you actually do inside actions / guards?
                Defining a simple state machine
                Defining a submachine
                Orthogonal regions, terminate state, event deferring
                History
                Completion (anonymous) transitions
                Internal transitions
                more row types
                Explicit entry / entry and exit pseudo-state / fork
                Flags
                Event Hierarchy
                Customizing a state machine / Getting more speed
                Choosing the initial event
                 Containing state machine (deprecated)
                Functor front-end
                 Transition table 
                Defining states with entry/exit actions
                What do you actually do inside actions / guards (Part 2)?
                Defining a simple state machine
                Anonymous transitions
                Internal
-                        transitions
                eUML (experimental)
                Transition table
                A simple example: rewriting only our transition table
                Defining events, actions and states with entry/exit actions
                Wrapping up a simple state machine and first complete examples
                Defining a submachine
                
-                        Attributes / Function call
                Orthogonal regions, flags, event deferring
                
+                        transitions
                eUML (experimental)
                Transition table
                A simple example: rewriting only our transition table 
                Defining events, actions and states with entry/exit actions
                Wrapping up a simple state machine and first complete examples
                Defining a submachine
                
+                        Attributes / Function call
                Orthogonal regions, flags, event deferring
                
                         Customizing a state machine / Getting
-                        more speed
                Completion / Anonymous transitions
                Internal transitions
                Other state types
                Helper functions
                Phoenix-like STL support
                Writing actions with Boost.Phoenix (in development)
                Back-end
                Creation 
                Starting and stopping a state
-                        machine
                Event dispatching
                Active state(s)
                Serialization
                Base state type 
                Visitor
                Flags
                Getting a state
                 State machine constructor with arguments 
                Trading run-time speed for
-                        better compile-time / multi-TU compilation
                Compile-time state machine analysis 
                 Enqueueing events for later
-                        processing 
                 Customizing the message queues 
                Policy definition with Boost.Parameter 
                Choosing when to switch active
-                        states 
                4.  Performance / Compilers
                Speed
                Executable size
                Supported compilers
                 Limitations 
                 Compilers corner 
                5. Questions & Answers, tips
                6. Internals
                Backend: Run To Completion
                Frontend / Backend
-                    interface
                 Generated state ids 
                Metaprogramming tools
                7. Acknowledgements
                MSM v2
                 MSM v1
                8. Version history
                From V2.21 to V2.22 (Boost 1.48)
                From V2.20 to V2.21 (Boost 1.47)
                From V2.12 to V2.20 (Boost 1.46)
                From V2.10 to V2.12  (Boost 1.45)
                From V2.0 to V2.12  (Boost 1.44)
                II. Reference
                9. eUML operators and basic helpers
                10. 
-                Functional programming 
                Common headers — The common types used by front- and back-ends
                Back-end — The back-end headers
                Front-end — The front-end headers
                List of Tables
                9.1. Operators and state machine helpers
                10.1. STL algorithms
                10.2. STL algorithms
                10.3. STL algorithms
                10.4. STL container methods
                10.5. STL list methods
                10.6. STL associative container methods 
                10.7. STL pair
                10.8. STL string
                   Next
                   Preface
                
\ No newline at end of file
+                        more speed
                Completion / Anonymous transitions
                Internal transitions
                Other state types
                Helper functions
                Phoenix-like STL support
                Writing actions with Boost.Phoenix (in development)
                Back-end
                Creation 
                Starting and stopping a state
+                        machine
                Event dispatching
                Active state(s)
                Serialization
                Base state type 
                Visitor
                Flags
                Getting a state
                 State machine constructor with arguments 
                Trading run-time speed for
+                        better compile-time / multi-TU compilation
                Compile-time state machine analysis 
                 Enqueueing events for later
+                        processing 
                 Customizing the message queues 
                Policy definition with Boost.Parameter 
                Choosing when to switch active
+                        states 
                4.  Performance / Compilers
                Speed
                Executable size
                Supported compilers
                 Limitations 
                 Compilers corner 
                5. Questions & Answers, tips
                6. Internals
                Backend: Run To Completion
                Frontend / Backend
+                    interface
                 Generated state ids 
                Metaprogramming tools
                7. Acknowledgements
                MSM v2
                 MSM v1
                8. Version history
                From V2.22 to V2.23 (Boost 1.50)
                From V2.21 to V2.22 (Boost 1.48)
                From V2.20 to V2.21 (Boost 1.47)
                From V2.12 to V2.20 (Boost 1.46)
                From V2.10 to V2.12  (Boost 1.45)
                From V2.0 to V2.12  (Boost 1.44)
                II. Reference
                9. eUML operators and basic helpers
                10. 
+                Functional programming 
                Common headers — The common types used by front- and back-ends
                Back-end — The back-end headers
                Front-end — The front-end headers
                List of Tables
                9.1. Operators and state machine helpers
                10.1. STL algorithms
                10.2. STL algorithms
                10.3. STL algorithms
                10.4. STL container methods
                10.5. STL list methods
                10.6. STL associative container methods 
                10.7. STL pair
                10.8. STL string
                   Next
                   Preface
                
\ No newline at end of file
diff --git a/doc/HTML/pr01.html b/doc/HTML/pr01.html
index 62cf7a9..4be5a21 100644
--- a/doc/HTML/pr01.html
+++ b/doc/HTML/pr01.html
@@ -1,6 +1,6 @@
 
       
-   Preface
                Preface
                Prev   Next
                Preface
                MSM is a library allowing you to easily and quickly define state machines of very high
+   Preface
                Preface
                Prev   Next
                Preface
                MSM is a library allowing you to easily and quickly define state machines of very high
             performance. From this point, two main questions usually quickly arise, so please allow
             me to try answering them upfront.
                
             
                msm/back/default_compile_policy.hpp
                This header contains the definition of favor_runtime_speed. This policy has
                     two settings:
                • Submachines dispatch faster because their transitions are added
                                 into their containing machine's transition table instead of simply
-                                forwarding events.
                • It solves transition conflicts at compile-time
                msm/back/favor_compile_time.hpp
                This header contains the definition of favor_compile_time. This policy has two settings:
                • Submachines dispatch is slower because all events, even those with
+                                forwarding events.
                • It solves transition conflicts at compile-time
                msm/back/favor_compile_time.hpp
                This header contains the definition of favor_compile_time. This policy has two settings:
                • Submachines dispatch is slower because all events, even those with
                                 no dispatch chance, are forwarded to submachines. In exchange, no
                                 row is added into the containing machine's transition table, which
-                                reduces compile-time.
                • It solves transition conflicts at run-time.
                msm/back/metafunctions.hpp 
                This header contains metafunctions for use by the library. Three metafunctions
+                                reduces compile-time.
              • It solves transition conflicts at run-time.
                • msm/back/metafunctions.hpp 
                This header contains metafunctions for use by the library. Three metafunctions
                     can be useful for the user:
                • generate_state_set< stt >: generates the list of
                                 all states referenced by the transition table stt. If stt is a
                                 recursive table (generated by
@@ -86,10 +86,10 @@
                                 finds recursively all events of the submachines. A non-recursive
                                 table can be obtained with some_backend_fsm::stt.
                • recursive_get_transition_table<fsm>: recursively
                                 extends the transition table of the state machine fsm with tables
-                                from the submachines.
                msm/back/tools.hpp 
                 This header contains a few metaprogramming tools to get some information out
-                    of a state machine.
                fill_state_names 
                attributes 
                 fill_state_names has for attribute:
                • char const** m_names: an already allocated
+                                from the submachines.
                msm/back/tools.hpp 
                 This header contains a few metaprogramming tools to get some information out
+                    of a state machine.
                fill_state_names 
                attributes 
                 fill_state_names has for attribute:
                • char const** m_names: an already allocated
                                         array of const char* where the typeid-generated names of a
-                                        state machine states will be witten.
                constructor 
                char const** names_to_fill(char const** names_to_fill);
                usage
                 fill_state_names is made for use in a mpl::for_each iterating on a
+                                        state machine states will be witten.
                constructor 
                char const** names_to_fill(char const** names_to_fill);
                usage
                 fill_state_names is made for use in a mpl::for_each iterating on a
                             state list and writing inside a pre-allocated array the state names.
                             Example:
                typedef some_fsm::stt Stt;
 typedef msm::back::generate_state_set<Stt>::type all_states; //states
@@ -104,10 +104,10 @@ for (unsigned int i=0;i<some_fsm::nr_regions::value;++i)
     std::cout << " -> " 
               << state_names[my_fsm_instance.current_state()[i]] 
               << std::endl;
-}
                get_state_name 
                 attributes 
                get_state_name has for attributes:
                • std::string& m_name: the return value of the
-                                        iteration
                • int m_state_id: the searched state's id
                constructor
                The constructor takes as argument a reference to the string to fill
-                            with the state name and the id which must be searched.
                string& name_to_fill,int state_id(string& name_to_fill,int state_id);
                 usage
                This type is made for the same search as in the previous example,
+}
                get_state_name 
                 attributes 
                get_state_name has for attributes:
                • std::string& m_name: the return value of the
+                                        iteration
                • int m_state_id: the searched state's id
                constructor
                The constructor takes as argument a reference to the string to fill
+                            with the state name and the id which must be searched.
                string& name_to_fill,int state_id(string& name_to_fill,int state_id);
                 usage
                This type is made for the same search as in the previous example,
                             using a mpl::for_each to iterate on states. After the iteration, the
-                            state name reference has been set.
                display_type 
                 attributes 
                none
                 usage
                Reusing the state list from the previous example, we can output all
+                            state name reference has been set.
                display_type 
                 attributes 
                none
                 usage
                Reusing the state list from the previous example, we can output all
                             state names:
                mpl::for_each<all_states,boost::msm::wrap<mpl::placeholders::_1>
                                 >(msm::back::display_type ());
                Prev Up Next
                Common headers Home Front-end
                
\ No newline at end of file
diff --git a/doc/HTML/re03.html b/doc/HTML/re03.html
index 159747a..5b6e40d 100644
--- a/doc/HTML/re03.html
+++ b/doc/HTML/re03.html
@@ -1,11 +1,11 @@
 
       
-   Front-end
                Front-end
                Prev Part II. Reference 
                Name
                Front-end — The front-end headers
                msm/front/common_states.hpp
                This header contains the predefined types to serve as base for states or state machines:
                • default_base_state: non-polymorphic empty type.
                • polymorphic_state: type with a virtual destructor, which makes all
-                                states polymorphic.
                msm/front/completion_event.hpp
                This header contains one type, none. This type has several
+   Front-end
                Front-end
                Prev Part II. Reference 
                Name
                Front-end — The front-end headers
                msm/front/common_states.hpp
                This header contains the predefined types to serve as base for states or state machines:
                • default_base_state: non-polymorphic empty type.
                • polymorphic_state: type with a virtual destructor, which makes all
+                                states polymorphic.
                msm/front/completion_event.hpp
                This header contains one type, none. This type has several
                     meanings inside a transition table:
                • as action or guard: that there is no action or guard
                • as target state: that the transition is an internal
                                 transition
                • as event: the transition is an anonymous (completion)
-                                transition
                msm/front/functor_row.hpp
                This header implements the functor front-end's transitions and helpers.
                Row
                definition
                 template <class Source,class Event,class Target,class
-                                    Action,class Guard> Row {
                }
                tags
                row_type_tag is defined differently for every specialization:
                • all 5 template parameters means a normal transition with
+                                transition
                msm/front/functor_row.hpp
                This header implements the functor front-end's transitions and helpers.
                Row
                definition
                 template <class Source,class Event,class Target,class
+                                    Action,class Guard> Row {
                }
                tags
                row_type_tag is defined differently for every specialization:
                • all 5 template parameters means a normal transition with
                                         action and guard: typedef row_tag
                                         row_type_tag;
                • Row<Source,Event,Target,none,none> a normal transition
                                         without action or guard: typedef _row_tag
@@ -21,7 +21,7 @@
                                         transition with action and guard: typedef irow_tag
                                             row_type_tag;
                • Row<Source,Event,none,none,none> an internal transition
                                         without action or guard: typedef _irow_tag
-                                            row_type_tag;
                methods
                Like any other front-end, Row implements the two necessary static
+                                            row_type_tag;
                methods
                Like any other front-end, Row implements the two necessary static
                             functions for action and guard call. Each function receives as parameter
                             the (deepest-level) state machine processsing the event, the event
                             itself, the source and target states and all the states contained in a
@@ -33,8 +33,8 @@
                                     class AllStates> static bool guard_call(
                		); 
                
                                     (Fsm& fsm,Event const&
                                         evt,SourceState&,TargetState,AllStates&)
-                                ;
                 
                Internal
                definition
                 template <class Event,class Action,class Guard>
-                                    Internal {
                }
                tags
                row_type_tag is defined differently for every specialization:
                • all 3 template parameters means an internal transition
+                                ;
                 
                Internal
                definition
                 template <class Event,class Action,class Guard>
+                                    Internal {
                }
                tags
                row_type_tag is defined differently for every specialization:
                • all 3 template parameters means an internal transition
                                         with action and guard: typedef sm_i_row_tag
                                             row_type_tag;
                • Internal<Event,none,none> an internal transition
                                         without action or guard: typedef sm__i_row_tag
@@ -42,7 +42,7 @@
                                         without guard: typedef sm_a_i_row_tag
                                             row_type_tag;
                • Internal<Event,none,Guard> an internal transition
                                         without action: typedef sm_g_i_row_tag
-                                            row_type_tag;
                methods
                Like any other front-end, Internal implements the two necessary static
+                                            row_type_tag;
                methods
                Like any other front-end, Internal implements the two necessary static
                             functions for action and guard call. Each function receives as parameter
                             the (deepest-level) state machine processsing the event, the event
                             itself, the source and target states and all the states contained in a
@@ -54,9 +54,9 @@
                                     class AllStates> static bool guard_call(
                		); 
                
                                     (Fsm& fsm,Event const&
                                         evt,SourceState&,TargetState,AllStates&)
-                                ;
                 
                ActionSequence_
                This functor calls every element of the template Sequence (which are also
+                                ;
                 
                ActionSequence_
                This functor calls every element of the template Sequence (which are also
                         callable functors) in turn. It is also the underlying implementation of the
-                        eUML sequence grammar (action1,action2,...).
                definition
                 template <class Sequence> ActionSequence_ {
                }
                methods
                This helper functor is made for use in a transition table and in a
+                        eUML sequence grammar (action1,action2,...).
                definition
                 template <class Sequence> ActionSequence_ {
                }
                methods
                This helper functor is made for use in a transition table and in a
                             state behavior and therefore implements an operator() with 3 and with 4
                             arguments:
                
                             
                template <class Evt,class Fsm,class
@@ -65,13 +65,13 @@
                         
                
                             
                template <class Evt,class Fsm,class State>
                                         operator()(); 
                Evt const&, Fsm&, State&;
                 
                
-                        
                Defer
                definition
                 Defer {
                }
                methods
                This helper functor is made for use in a transition table and
+                        
                Defer
                definition
                 Defer {
                }
                methods
                This helper functor is made for use in a transition table and
                             therefore implements an operator() with 4 arguments:
                template <class Evt,class Fsm,class SourceState,class
                                     TargetState> operator()(); 
                Evt const&, Fsm& , SourceState&,
-                                    TargetState&;
                 
                msm/front/internal_row.hpp
                This header implements the internal transition rows for use inside an
+                                    TargetState&;
                 
                msm/front/internal_row.hpp
                This header implements the internal transition rows for use inside an
                     internal_transition_table. All these row types have no source or target state,
                     as the backend will recognize internal transitions from this
-                    internal_transition_table.
                methods
                Like any other front-end, the following transition row types implements
+                    internal_transition_table.
                methods
                Like any other front-end, the following transition row types implements
                         the two necessary static functions for action and guard call. Each function
                         receives as parameter the (deepest-level) state machine processsing the
                         event, the event itself, the source and target states and all the states
@@ -83,30 +83,30 @@
                                 class AllStates> static bool guard_call(
                		); 
                
                                 (Fsm& fsm,Event const&
                                     evt,SourceState&,TargetState,AllStates&)
-                            ;
                 
                a_internal
                definition
                This is an internal transition with an action called during the
+                            ;
                 
                a_internal
                definition
                This is an internal transition with an action called during the
                             transition.
                 template< class Event, class CalledForAction, void
                                     (CalledForAction::*action)(Event const&)>
-                                    a_internal {
                }
                template parameters
                
+                                    a_internal {
                }
                template parameters
                
                             
                • Event: the event triggering the internal
                                         transition.
                • CalledForAction: the type on which the action method will
                                         be called. It can be either a state of the containing state
                                         machine or the state machine itself.
                • action: a pointer to the method which CalledForAction
                                         provides.
                
-                        
                g_internal
                This is an internal transition with a guard called before the transition
-                        and allowing the transition if returning true.
                definition
                 template< class Event, class CalledForGuard, bool
+                        
                g_internal
                This is an internal transition with a guard called before the transition
+                        and allowing the transition if returning true.
                definition
                 template< class Event, class CalledForGuard, bool
                                     (CalledForGuard::*guard)(Event const&)>
-                                    g_internal {
                }
                template parameters
                
+                                    g_internal {
                }
                template parameters
                
                             
                • Event: the event triggering the internal
                                         transition.
                • CalledForGuard: the type on which the guard method will be
                                         called. It can be either a state of the containing state
                                         machine or the state machine itself.
                • guard: a pointer to the method which CalledForGuard
                                         provides.
                
-                        
                internal
                This is an internal transition with a guard called before the transition
+                        
                internal
                This is an internal transition with a guard called before the transition
                         and allowing the transition if returning true. It also calls an action
-                        called during the transition.
                definition
                 template< class Event, class CalledForAction, void
+                        called during the transition.
                definition
                 template< class Event, class CalledForAction, void
                                     (CalledForAction::*action)(Event const&), class
                                     CalledForGuard, bool (CalledForGuard::*guard)(Event const&)>
-                                    internal {
                }
                template parameters
                
+                                    internal {
                }
                template parameters
                
                             
                • Event: the event triggering the internal transition
                • CalledForAction: the type on which the action method will
                                         be called. It can be either a state of the containing state
                                         machine or the state machine itself.
                • action: a pointer to the method which CalledForAction
@@ -114,15 +114,15 @@
                                         called. It can be either a state of the containing state
                                         machine or the state machine itself.
                • guard: a pointer to the method which CalledForGuard
                                         provides.
                
-                        
                _internal
                This is an internal transition without action or guard. This is equivalent
-                        to an explicit "ignore event".
                definition
                 template< class Event > _internal {
                }
                template parameters
                
+                        
                _internal
                This is an internal transition without action or guard. This is equivalent
+                        to an explicit "ignore event".
                definition
                 template< class Event > _internal {
                }
                template parameters
                
                             
                • Event: the event triggering the internal
                                         transition.
                
-                        
                msm/front/row2.hpp
                This header contains the variants of row2, which are an extension of the
+                        
                msm/front/row2.hpp
                This header contains the variants of row2, which are an extension of the
                     standard row transitions for use in the transition table. They offer the
                     possibility to define action and guard not only in the state machine, but in any
                     state of the state machine. They can also be used in internal transition tables
-                    through their irow2 variants.
                methods
                Like any other front-end, the following transition row types implements
+                    through their irow2 variants.
                methods
                Like any other front-end, the following transition row types implements
                         the two necessary static functions for action and guard call. Each function
                         receives as parameter the (deepest-level) state machine processsing the
                         event, the event itself, the source and target states and all the states
@@ -134,28 +134,28 @@
                                 class AllStates> static bool guard_call(
                		); 
                
                                 (Fsm& fsm,Event const&
                                     evt,SourceState&,TargetState,AllStates&)
-                            ;
                 
                _row2
                This is a transition without action or guard. The state machine only
-                        changes active state.
                definition
                 template< class Source, class Event, class Target >
-                                    _row2 {
                }
                template parameters
                
+                            ;
                 
                _row2
                This is a transition without action or guard. The state machine only
+                        changes active state.
                definition
                 template< class Source, class Event, class Target >
+                                    _row2 {
                }
                template parameters
                
                             
                • Event: the event triggering the transition.
                • Source: the source state of the transition.
                • Target: the target state of the transition.
                
-                        
                a_row2
                This is a transition with action and without guard.
                definition
                 template< class Source, class Event, class Target,
+                        
                a_row2
                This is a transition with action and without guard.
                definition
                 template< class Source, class Event, class Target,
                                  {
                }
                 class CalledForAction, void
-                                    (CalledForAction::*action)(Event const&) > _row2 {
                }
                template parameters
                
+                                    (CalledForAction::*action)(Event const&) > _row2 {
                }
                template parameters
                
                             
                • Event: the event triggering the transition.
                • Source: the source state of the transition.
                • Target: the target state of the transition.
                • CalledForAction: the type on which the action method will
                                         be called. It can be either a state of the containing state
                                         machine or the state machine itself.
                • action: a pointer to the method which CalledForAction
                                         provides.
                
-                        
                g_row2
                This is a transition with guard and without action.
                definition
                 template< class Source, class Event, class Target,
+                        
                g_row2
                This is a transition with guard and without action.
                definition
                 template< class Source, class Event, class Target,
                                  {
                }
                 class CalledForGuard, bool (CalledForGuard::*guard)(Event
-                                    const&) > _row2 {
                }
                template parameters
                
+                                    const&) > _row2 {
                }
                template parameters
                
                             
                • Event: the event triggering the transition.
                • Source: the source state of the transition.
                • Target: the target state of the transition.
                • CalledForGuard: the type on which the guard method will be
                                         called. It can be either a state of the containing state
                                         machine or the state machine itself.
                • guard: a pointer to the method which CalledForGuard
                                         provides.
                
-                        
                row2
                This is a transition with guard and action.
                definition
                 template< class Source, class Event, class Target,
+                        
                row2
                This is a transition with guard and action.
                definition
                 template< class Source, class Event, class Target,
                                  {
                }
                 class CalledForAction, void
                                     (CalledForAction::*action)(Event const&),  {
                }
                 class CalledForGuard, bool (CalledForGuard::*guard)(Event
-                                    const&) > _row2 {
                }
                template parameters
                
+                                    const&) > _row2 {
                }
                template parameters
                
                             
                • Event: the event triggering the transition.
                • Source: the source state of the transition.
                • Target: the target state of the transition.
                • CalledForAction: the type on which the action method will
                                         be called. It can be either a state of the containing state
                                         machine or the state machine itself.
                • action: a pointer to the method which CalledForAction
@@ -163,24 +163,24 @@
                                         called. It can be either a state of the containing state
                                         machine or the state machine itself.
                • guard: a pointer to the method which CalledForGuard
                                         provides.
                
-                        
                a_irow2
                This is an internal transition for use inside a transition table, with
-                        action and without guard.
                definition
                 template< class Source, class Event,  {
                }
                 class CalledForAction, void
-                                    (CalledForAction::*action)(Event const&) > _row2 {
                }
                template parameters
                
+                        
                a_irow2
                This is an internal transition for use inside a transition table, with
+                        action and without guard.
                definition
                 template< class Source, class Event,  {
                }
                 class CalledForAction, void
+                                    (CalledForAction::*action)(Event const&) > _row2 {
                }
                template parameters
                
                             
                • Event: the event triggering the transition.
                • Source: the source state of the transition.
                • CalledForAction: the type on which the action method will
                                         be called. It can be either a state of the containing state
                                         machine or the state machine itself.
                • action: a pointer to the method which CalledForAction
                                         provides.
                
-                        
                g_irow2
                This is an internal transition for use inside a transition table, with
-                        guard and without action.
                definition
                 template< class Source, class Event,  {
                }
                 class CalledForGuard, bool (CalledForGuard::*guard)(Event
-                                    const&) > _row2 {
                }
                template parameters
                
+                        
                g_irow2
                This is an internal transition for use inside a transition table, with
+                        guard and without action.
                definition
                 template< class Source, class Event,  {
                }
                 class CalledForGuard, bool (CalledForGuard::*guard)(Event
+                                    const&) > _row2 {
                }
                template parameters
                
                             
                • Event: the event triggering the transition.
                • Source: the source state of the transition.
                • CalledForGuard: the type on which the guard method will be
                                         called. It can be either a state of the containing state
                                         machine or the state machine itself.
                • guard: a pointer to the method which CalledForGuard
                                         provides.
                
-                        
                irow2
                This is an internal transition for use inside a transition table, with
-                        guard and action.
                definition
                 template< class Source, class Event,  {
                }
                 class CalledForAction, void
+                        
                irow2
                This is an internal transition for use inside a transition table, with
+                        guard and action.
                definition
                 template< class Source, class Event,  {
                }
                 class CalledForAction, void
                                     (CalledForAction::*action)(Event const&),  {
                }
                 class CalledForGuard, bool (CalledForGuard::*guard)(Event
-                                    const&) > _row2 {
                }
                template parameters
                
+                                    const&) > _row2 {
                }
                template parameters
                
                             
                • Event: the event triggering the transition.
                • Source: the source state of the transition.
                • CalledForAction: the type on which the action method will
                                         be called. It can be either a state of the containing state
                                         machine or the state machine itself.
                • action: a pointer to the method which CalledForAction
@@ -188,16 +188,16 @@
                                         called. It can be either a state of the containing state
                                         machine or the state machine itself.
                • guard: a pointer to the method which CalledForGuard
                                         provides.
                
-                        
                msm/front/state_machine_def.hpp
                This header provides the implementation of the basic front-end. It contains one
-                    type, state_machine_def
                state_machine_def definition
                This type is the basic class for a basic (or possibly any other)
+                        
                msm/front/state_machine_def.hpp
                This header provides the implementation of the basic front-end. It contains one
+                    type, state_machine_def
                state_machine_def definition
                This type is the basic class for a basic (or possibly any other)
                         front-end. It provides the standard row types (which includes internal
                         transitions) and a default implementation of the required methods and
                         typedefs.
                 template <class Derived,class BaseState =
-                                default_base_state> state_machine_def {
                }
                typedefs
                
+                                default_base_state> state_machine_def {
                }
                typedefs
                
                             
                • flag_list: by default, no flag is set in the state
                                         machine
                • deferred_events: by default, no event is deferred.
                • configuration: by default, no configuration customization
                                         is done.
                
-                        
                row methods
                Like any other front-end, the following transition row types
+                        
                row methods
                Like any other front-end, the following transition row types
                             implements the two necessary static functions for action and guard call.
                             Each function receives as parameter the (deepest-level) state machine
                             processsing the event, the event itself, the source and target states
@@ -209,30 +209,30 @@
                                     class AllStates> static bool guard_call(
                		); 
                
                                     (Fsm& fsm,Event const&
                                         evt,SourceState&,TargetState,AllStates&)
-                                ;
                 
                a_row
                This is a transition with action and without guard.
                template< class Source, class Event, class Target,
+                                ;
                 
                a_row
                This is a transition with action and without guard.
                template< class Source, class Event, class Target,
                                     void (Derived::*action)(Event const&) > a_row
                • Event: the event triggering the transition.
                • Source: the source state of the transition.
                • Target: the target state of the transition.
                • action: a pointer to the method provided by the concrete
-                                        front-end (represented by Derived).
                g_row
                This is a transition with guard and without action.
                template< class Source, class Event, class Target,
+                                        front-end (represented by Derived).
                g_row
                This is a transition with guard and without action.
                template< class Source, class Event, class Target,
                                     bool (Derived::*guard)(Event const&) > g_row
                • Event: the event triggering the transition.
                • Source: the source state of the transition.
                • Target: the target state of the transition.
                • guard: a pointer to the method provided by the concrete
-                                        front-end (represented by Derived).
                row
                This is a transition with guard and action.
                template< class Source, class Event, class Target,
+                                        front-end (represented by Derived).
                row
                This is a transition with guard and action.
                template< class Source, class Event, class Target,
                                     void (Derived::*action)(Event const&), bool
                                     (Derived::*guard)(Event const&) > row
                • Event: the event triggering the transition.
                • Source: the source state of the transition.
                • Target: the target state of the transition.
                • action: a pointer to the method provided by the concrete
                                         front-end (represented by Derived).
                • guard: a pointer to the method provided by the concrete
-                                        front-end (represented by Derived).
                _row
                This is a transition without action or guard. The state machine only
+                                        front-end (represented by Derived).
                _row
                This is a transition without action or guard. The state machine only
                             changes active state.
                template< class Source, class Event, class Target >
-                                    _row
                • Event: the event triggering the transition.
                • Source: the source state of the transition.
                • Target: the target state of the transition.
                a_irow
                This is an internal transition for use inside a transition table, with
+                                    _row
                • Event: the event triggering the transition.
                • Source: the source state of the transition.
                • Target: the target state of the transition.
                a_irow
                This is an internal transition for use inside a transition table, with
                             action and without guard.
                template< class Source, class Event, void
                                     (Derived::*action)(Event const&) > a_irow
                • Event: the event triggering the transition.
                • Source: the source state of the transition.
                • action: a pointer to the method provided by the concrete
-                                        front-end (represented by Derived).
                g_irow
                This is an internal transition for use inside a transition table, with
+                                        front-end (represented by Derived).
                g_irow
                This is an internal transition for use inside a transition table, with
                             guard and without action.
                template< class Source, class Event, bool
                                     (Derived::*guard)(Event const&) > g_irow
                • Event: the event triggering the transition.
                • Source: the source state of the transition.
                • guard: a pointer to the method provided by the concrete
-                                        front-end (represented by Derived).
                irow
                This is an internal transition for use inside a transition table, with
+                                        front-end (represented by Derived).
                irow
                This is an internal transition for use inside a transition table, with
                             guard and action.
                template< class Source, class Event, void
                                     (Derived::*action)(Event const&), bool
                                     (Derived::*guard)(Event const&) > irow
                • Event: the event triggering the transition.
                • Source: the source state of the transition.
                • action: a pointer to the method provided by the concrete
                                         front-end (represented by Derived).
                • guard: a pointer to the method provided by the concrete
-                                        front-end (represented by Derived).
                _irow
                This is an internal transition without action or guard. As it does
+                                        front-end (represented by Derived).
                _irow
                This is an internal transition without action or guard. As it does
                             nothing, it means "ignore event".
                template< class Source, class Event >
-                                    _irow
                • Event: the event triggering the transition.
                • Source: the source state of the transition.
                methods
                state_machine_def provides a default implementation in
+                                    _irow
                • Event: the event triggering the transition.
                • Source: the source state of the transition.
                methods
                state_machine_def provides a default implementation in
                             case of an event which cannot be processed by a state machine (no
                             transition found). The implementation is using a
                                 BOOST_ASSERT so that the error will only be noticed in
@@ -256,30 +256,30 @@
                                         (Event const& ,Fsm&,
                                             std::exception&)
                                     ;
                 
                
-                        
                msm/front/states.hpp 
                This header provides the different states (except state machines) for the
-                    basic front-end (or mixed with other front-ends).
                types
                This header provides the following types:
                no_sm_ptr
                deprecated: default policy for states. It means that states do not
-                            need to save a pointer to their containing state machine.
                sm_ptr
                deprecated: state policy. It means that states need to save a pointer
+                        
                msm/front/states.hpp 
                This header provides the different states (except state machines) for the
+                    basic front-end (or mixed with other front-ends).
                types
                This header provides the following types:
                no_sm_ptr
                deprecated: default policy for states. It means that states do not
+                            need to save a pointer to their containing state machine.
                sm_ptr
                deprecated: state policy. It means that states need to save a pointer
                             to their containing state machine. When seeing this flag, the back-end
-                            will call set_sm_ptr(fsm*) and give itself as argument.
                state
                Basic type for simple states. Inherit from this type to define a
+                            will call set_sm_ptr(fsm*) and give itself as argument.
                state
                Basic type for simple states. Inherit from this type to define a
                             simple state. The first argument is needed if you want your state (and
                             all others used in a concrete state machine) to inherit a basic type for
                             logging or providing a common behavior.
                 template<class Base = default_base_state,class
-                                    SMPtrPolicy = no_sm_ptr> state {
                }
                terminate_state
                Basic type for terminate states. Inherit from this type to define a
+                                    SMPtrPolicy = no_sm_ptr> state {
                }
                terminate_state
                Basic type for terminate states. Inherit from this type to define a
                             terminate state. The first argument is needed if you want your state
                             (and all others used in a concrete state machine) to inherit a basic
                             type for logging or providing a common behavior.
                 template<class Base = default_base_state,class
-                                    SMPtrPolicy = no_sm_ptr> terminate_state {
                }
                interrupt_state
                Basic type for interrupt states. Interrupt states prevent any further
+                                    SMPtrPolicy = no_sm_ptr> terminate_state {
                }
                interrupt_state
                Basic type for interrupt states. Interrupt states prevent any further
                             event handling until EndInterruptEvent is sent. Inherit from this type
                             to define a terminate state. The first argument is the name of the event
                             ending the interrupt. The second argument is needed if you want your
                             state (and all others used in a concrete state machine) to inherit a
                             basic type for logging or providing a common behavior.
                 template<class EndInterruptEvent,class Base =
                                     default_base_state, {
                }
                 class SMPtrPolicy = no_sm_ptr>
-                                    interrupt_state {
                }
                explicit_entry
                Inherit from this type in
+                                    interrupt_state {
                }
                explicit_entry
                Inherit from this type in
                                 addition to the desired state type to enable this state
                             for direct entering. The template parameter gives the region id of the
                             state (regions are numbered in the order of the
-                                initial_state typedef).
                 template <int ZoneIndex=-1> explicit_entry {
                }
                entry_pseudo_state
                Basic type for entry pseudo states. Entry pseudo states are an
+                                initial_state typedef).
                 template <int ZoneIndex=-1> explicit_entry {
                }
                entry_pseudo_state
                Basic type for entry pseudo states. Entry pseudo states are an
                             predefined entry into a submachine and connect two transitions. The
                             first argument is the id of the region entered by this state (regions
                             are numbered in the order of the initial_state typedef).
@@ -287,7 +287,7 @@
                             used in a concrete state machine) to inherit a basic type for logging or
                             providing a common behavior.
                 template<int RegionIndex=-1,class Base =
                                     default_base_state, {
                }
                 class SMPtrPolicy = no_sm_ptr>
-                                    entry_pseudo_state {
                }
                exit_pseudo_state
                Basic type for exit pseudo states. Exit pseudo states are an
+                                    entry_pseudo_state {
                }
                exit_pseudo_state
                Basic type for exit pseudo states. Exit pseudo states are an
                             predefined exit from a submachine and connect two transitions. The first
                             argument is the name of the event which will be "thrown" out of the exit
                             point. This event does not need to be the same as the one sent by the
@@ -296,32 +296,32 @@
                             machine) to inherit a basic type for logging or providing a common
                             behavior.
                 template<class Event,class Base =
                                     default_base_state, {
                }
                 class SMPtrPolicy = no_sm_ptr>
-                                    exit_pseudo_state {
                }
                msm/front/euml/euml.hpp
                This header includes all of eUML except the STL functors.
                msm/front/euml/stl.hpp
                This header includes all the functors for STL support in eUML. These tables show a full description.
                msm/front/euml/algorithm.hpp
                This header includes all the functors for STL algorithms support in eUML.
+                                    exit_pseudo_state {
                }
                msm/front/euml/euml.hpp
                This header includes all of eUML except the STL functors.
                msm/front/euml/stl.hpp
                This header includes all the functors for STL support in eUML. These tables show a full description.
                msm/front/euml/algorithm.hpp
                This header includes all the functors for STL algorithms support in eUML.
                     These tables show a full
-                    description.
                msm/front/euml/iteration.hpp
                This header includes iteration functors for STL support in eUML. This tables shows a full
-                    description.
                msm/front/euml/querying.hpp
                This header includes querying functors for STL support in eUML. This tables shows a full
-                    description.
                msm/front/euml/transformation.hpp
                This header includes transformation functors for STL support in eUML. This
+                    description.
                msm/front/euml/iteration.hpp
                This header includes iteration functors for STL support in eUML. This tables shows a full
+                    description.
                msm/front/euml/querying.hpp
                This header includes querying functors for STL support in eUML. This tables shows a full
+                    description.
                msm/front/euml/transformation.hpp
                This header includes transformation functors for STL support in eUML. This
                         tables shows a full
-                    description.
                msm/front/euml/container.hpp
                This header includes container functors for STL support in eUML (functors
+                    description.
                msm/front/euml/container.hpp
                This header includes container functors for STL support in eUML (functors
                     calling container methods). This tables shows a full description. It also provides npos for
-                    strings.
                Npos_<container type>
                Functor returning npos for transition or state behaviors. Like all
+                    strings.
                Npos_<container type>
                Functor returning npos for transition or state behaviors. Like all
                         constants, only the functor form exists, so parenthesis are necessary.
                         Example:
                string_find_(event_(m_song),Char_<'S'>(),Size_t_<0>()) !=
                             Npos_<string>() // compare result of string::find with
-                        npos
                msm/front/euml/stt_grammar.hpp
                This header provides the transition table grammars. This includes internal
-                    transition tables.
                functions
                build_stt
                The function build_stt evaluates the grammar-conform expression as
+                        npos
                msm/front/euml/stt_grammar.hpp
                This header provides the transition table grammars. This includes internal
+                    transition tables.
                functions
                build_stt
                The function build_stt evaluates the grammar-conform expression as
                             parameter. It returns a transition table, which is a mpl::vector of
                             transitions (rows) or, if the expression is ill-formed (does not match
                             the grammar), the type invalid_type, which will lead to a
                             compile-time static assertion when this transition table is passed to a
                             state machine. 
                template<class Expr> [mpl::vector<...> /
-                                    msm::front::euml::invalid_type] build_stt(); 
                Expr const& expr;
                 
                build_internal_stt
                The function build_internal_stt evaluates the grammar-conform
+                                    msm::front::euml::invalid_type] build_stt(
                		); 
                Expr const& expr;
                 
                build_internal_stt
                The function build_internal_stt evaluates the grammar-conform
                             expression as parameter. It returns a transition table, which is a
                             mpl::vector of transitions (rows) or, if the expression is ill-formed
                             (does not match the grammar), the type invalid_type, which
                             will lead to a compile-time static assertion when this transition table
                             is passed to a state machine. 
                template<class Expr> [mpl::vector<...> /
-                                    msm::front::euml::invalid_type] build_internal_stt(); 
                Expr const& expr;
                 
                grammars
                transition
+                                    msm::front::euml::invalid_type] build_internal_stt(
                		); 
                Expr const& expr;
                 
                grammars
                transition
                             table
                The transition table accepts the following grammar:
                Stt := Row | (Stt ',' Stt)
 Row := (Target '==' (SourcePlusEvent)) /* first syntax*/
        | ( (SourcePlusEvent) '==' Target ) /* second syntax*/
@@ -346,15 +346,15 @@ target == source + event / action,
 source + event /action == target,
 source / action == target, /*anonymous transition*/
 target == source / action, /*anonymous transition*/
-source + event /action, /* internal transition*/
                internal transition table
                The internal transition table accepts the following grammar:
                IStt := BuildEvent | (IStt ',' IStt)
                BuildEvent being defined for both internal and standard transition
-                            tables.
                msm/front/euml/guard_grammar.hpp
                This header contains the Guard grammar used in the previous
+source + event /action, /* internal transition*/
                internal transition table
                The internal transition table accepts the following grammar:
                IStt := BuildEvent | (IStt ',' IStt)
                BuildEvent being defined for both internal and standard transition
+                            tables.
                msm/front/euml/guard_grammar.hpp
                This header contains the Guard grammar used in the previous
                     section. This grammar is long but pretty simple:
                Guard := action_tag | (Guard '&&' Guard) 
         | (Guard '||' Guard) | ... /* operators*/
         | (if_then_else_(Guard,Guard,Guard)) | (function (Action,...Action))
                Most C++ operators are supported (address-of is not). With
                         function is meant any eUML predefined function or any self-made
                     (using MSM_EUML_METHOD or MSM_EUML_FUNCTION). Action
-                    is a grammar defined in state_grammar.hpp.
                msm/front/euml/state_grammar.hpp
                This header provides the grammar for actions and the different grammars and
-                    functions to build states using eUML.
                action grammar
                Like the guard grammar, this grammar supports relevant C++ operators and
+                    is a grammar defined in state_grammar.hpp.
                msm/front/euml/state_grammar.hpp
                This header provides the grammar for actions and the different grammars and
+                    functions to build states using eUML.
                action grammar
                Like the guard grammar, this grammar supports relevant C++ operators and
                         eUML functions:
                Action := action_tag | (Action '+' Action) 
           | ('--' Action) | ... /* operators*/
           | if_then_else_(Guard,Action,Action) | if_then_(Action) 
@@ -363,10 +363,10 @@ source + event /action, /* internal transition*/
                attributes
                This grammar is used to add attributes to states (or state machines) or
+                        ^(bitwise), +=, -=, *=, /=, %=, <<=, >>=, <<, >>, =, [].
                attributes
                This grammar is used to add attributes to states (or state machines) or
                         events: It evaluates to a fusion::map. You can use two forms:
                • attributes_ << no_attributes_
                • attributes_ << attribute_1 << ... <<
                                         attribute_n
                Attributes can be of any default-constructible type (fusion
-                        requirement).
                configure
                This grammar also has two forms:
                • configure_ << no_configure_
                • configure_ << type_1 << ... <<
+                        requirement).
                configure
                This grammar also has two forms:
                • configure_ << no_configure_
                • configure_ << type_1 << ... <<
                                         type_n
                This grammar is used to create inside one syntax:
                • flags: configure_ << some_flag where
                                     some_flag inherits from euml_flag<some_flag> or
                                     is defined using BOOST_MSM_EUML_FLAG.
                • deferred events: configure_ << some_event
@@ -378,12 +378,12 @@ ActionSequence := Action | (Action ',' Action)
                  Relevant operators are: +
                                     some_config inherits from
                                         euml_config<some_config>. At the moment,
                                     three predefined objects exist (in msm//front/euml/common.hpp):
                  • no_exception: disable catching exceptions
                  • no_msg_queue: disable message queue
                  • deferred_events: manually enable handling of
-                                                deferred events
                initial states
                The grammar to define initial states for a state machine is: init_
+                                                deferred events
                initial states
                The grammar to define initial states for a state machine is: init_
                             << state_1 << ... << state_n where
                         state_1...state_n inherit from euml_state or is defined using
                         BOOST_MSM_EUML_STATE, BOOST_MSM_EUML_INTERRUPT_STATE,
                         BOOST_MSM_EUML_TERMINATE_STATE, BOOST_MSM_EUML_EXPLICIT_ENTRY_STATE,
-                        BOOST_MSM_EUML_ENTRY_STATE or BOOST_MSM_EUML_EXIT_STATE.
                functions
                build_sm
                This function has several overloads. The return type is not relevant
+                        BOOST_MSM_EUML_ENTRY_STATE or BOOST_MSM_EUML_EXIT_STATE.
                functions
                build_sm
                This function has several overloads. The return type is not relevant
                             to you as only decltype (return type) is what one needs.
                Defines a state machine without entry or exit:
                template <class StateNameTag,class Stt,class Init>
                                     func_state_machine<...> build_sm(); 
                Stt ,Init;
                 
                Defines a state machine with entry behavior:
                template <class StateNameTag,class Stt,class Init,class
                                     Expr1> func_state_machine<...> build_sm(); 
                Stt ,Init,Expr1 const&;
                 
                Defines a state machine with entry and exit behaviors:
                template <class StateNameTag,class Stt,class Init,class
@@ -402,7 +402,7 @@ ActionSequence := Action | (Action ',' Action)
                Relevant operators are: +
                                     Base> func_state_machine<...> build_sm(
                		); 
                Stt ,Init,Expr1 const&, Expr2 const&, Attributes
                                     const&, Configure const&, Base;
                 
                Notice that this function requires the extra parameter class
                             StateNameTag to disambiguate state machines having the same parameters
-                            but still being different.
                build_state
                This function has several overloads. The return type is not relevant
+                            but still being different.
                build_state
                This function has several overloads. The return type is not relevant
                             to you as only decltype (return type) is what one needs.
                Defines a simple state without entry or exit:
                func_state<class StateNameTag,...> build_state(); 
                ;
                 
                Defines a simple state with entry behavior:
                template <class StateNameTag,class Expr1>
                                     func_state<...> build_state(); 
                Expr1 const&;
                 
                Defines a simple state with entry and exit behaviors:
                template <class StateNameTag,class Expr1, class Expr2>
                                     func_state<...> build_state(); 
                Expr1 const&,Expr2 const&;
                 
                Defines a simple state with entry, exit behaviors and
@@ -418,7 +418,7 @@ ActionSequence := Action | (Action ',' Action)
                Relevant operators are: +
                                     func_state<...> build_state(
                		); 
                Expr1 const&, Expr2 const&, Attributes const&,
                                     Configure const&, Base;
                 
                Notice that this function requires the extra parameter class
                             StateNameTag to disambiguate states having the same parameters but still
-                            being different.
                build_terminate_state
                This function has the same overloads as build_state.
                build_interrupt_state
                This function has several overloads. The return type is not relevant
+                            being different.
                build_terminate_state
                This function has the same overloads as build_state.
                build_interrupt_state
                This function has several overloads. The return type is not relevant
                             to you as only decltype (return type) is what one needs.
                Defines an interrupt state without entry or exit:
                template <class StateNameTag,class EndInterruptEvent>
                                     func_state<...> build_interrupt_state(); 
                EndInterruptEvent const&;
                 
                Defines an interrupt state with entry behavior:
                template <class StateNameTag,class
                                     EndInterruptEvent,class Expr1> func_state<...>
@@ -443,7 +443,7 @@ ActionSequence := Action | (Action ',' Action)
                Relevant operators are: +
                                     const&, Attributes const&, Configure const&,
                                     Base;
                 
                Notice that this function requires the extra parameter class
                             StateNameTag to disambiguate states having the same parameters but still
-                            being different.
                build_entry_state
                This function has several overloads. The return type is not relevant
+                            being different.
                build_entry_state
                This function has several overloads. The return type is not relevant
                             to you as only decltype (return type) is what one needs.
                Defines an entry pseudo state without entry or exit:
                template <class StateNameTag,int RegionIndex>
                                     entry_func_state<...> build_entry_state(); 
                ;
                 
                Defines an entry pseudo state with entry behavior:
                template <class StateNameTag,int RegionIndex,class
                                     Expr1> entry_func_state<...> build_entry_state(); 
                Expr1 const&;
                 
                Defines an entry pseudo state with entry and exit behaviors:
                template <class StateNameTag,int RegionIndex,class
@@ -462,7 +462,7 @@ ActionSequence := Action | (Action ',' Action)
                Relevant operators are: +
                                     Base> entry_func_state<...> build_entry_state(
                		); 
                Expr1 const&, Expr2 const&, Attributes const&,
                                     Configure const&, Base;
                 
                Notice that this function requires the extra parameter class
                             StateNameTag to disambiguate states having the same parameters but still
-                            being different.
                build_exit_state
                This function has several overloads. The return type is not relevant
+                            being different.
                build_exit_state
                This function has several overloads. The return type is not relevant
                             to you as only decltype (return type) is what one needs.
                Defines an exit pseudo state without entry or exit:
                template <class StateNameTag,class Event>
                                     exit_func_state<...> build_exit_state(); 
                Event const&;
                 
                Defines an exit pseudo state with entry behavior:
                template <class StateNameTag,class Event,class Expr1>
                                     exit_func_state<...> build_exit_state(); 
                Event const&,Expr1 const&;
                 
                Defines an exit pseudo state with entry and exit behaviors:
                template <class StateNameTag,class Event,class Expr1,
@@ -481,8 +481,8 @@ ActionSequence := Action | (Action ',' Action)
                Relevant operators are: +
                                     exit_func_state<...> build_exit_state(
                		); 
                Event const&,Expr1 const&, Expr2 const&,
                                     Attributes const&, Configure const&, Base;
                 
                Notice that this function requires the extra parameter class
                             StateNameTag to disambiguate states having the same parameters but still
-                            being different.
                build_explicit_entry_state
                This function has the same overloads as build_entry_state and
-                            explicit_entry_func_state as return type.
                msm/front/euml/common.hpp
                types
                euml_event
                The basic type for events with eUML.
                 template <class EventName> euml_event; {
                }
                struct play : euml_event<play>{};
                euml_state
                The basic type for states with eUML. You will usually not use this
+                            being different.
                build_explicit_entry_state
                This function has the same overloads as build_entry_state and
+                            explicit_entry_func_state as return type.
                msm/front/euml/common.hpp
                types
                euml_event
                The basic type for events with eUML.
                 template <class EventName> euml_event; {
                }
                struct play : euml_event<play>{};
                euml_state
                The basic type for states with eUML. You will usually not use this
                             type directly as it is easier to use BOOST_MSM_EUML_STATE,
                             BOOST_MSM_EUML_INTERRUPT_STATE, BOOST_MSM_EUML_TERMINATE_STATE,
                             BOOST_MSM_EUML_EXPLICIT_ENTRY_STATE, BOOST_MSM_EUML_ENTRY_STATE or
@@ -493,7 +493,7 @@ ActionSequence := Action | (Action ',' Action)
                Relevant operators are: +
     void foo() {...}
     template <class Event,class Fsm>
     void on_entry(Event const& evt,Fsm& fsm){...}
-};
                euml_flag
                The basic type for flags with eUML.
                 template <class FlagName> euml_flag; {
                }
                struct PlayingPaused: euml_flag<PlayingPaused>{};
                euml_action
                The basic type for state or transition behaviors and guards with
+};
                euml_flag
                The basic type for flags with eUML.
                 template <class FlagName> euml_flag; {
                }
                struct PlayingPaused: euml_flag<PlayingPaused>{};
                euml_action
                The basic type for state or transition behaviors and guards with
                             eUML.
                 template <class AcionName> euml_action; {
                }
                struct close_drawer : euml_action<close_drawer>
 {
     template <class Fsm,class Evt,class SourceState,class TargetState>
@@ -502,41 +502,41 @@ ActionSequence := Action | (Action ',' Action)
                Relevant operators are: +
 {
     template <class Event,class Fsm,class State>
     void operator()(Event const&,Fsm& fsm,State& ){...}
-};
                euml_config
                The basic type for configuration possibilities with eUML.
                 template <class ConfigName> euml_config; {
                }
                You normally do not use this type directly but instead the instances
+};
                euml_config
                The basic type for configuration possibilities with eUML.
                 template <class ConfigName> euml_config; {
                }
                You normally do not use this type directly but instead the instances
                             of predefined configuration:
                • no_exception: disable catching exceptions
                • no_msg_queue: disable message queue. The message queue
                                         allows you to send an event for procesing while in an event
                                         processing.
                • deferred_events: manually enable handling of deferred
-                                        events
                invalid_type
                Type returned by grammar parsers if the grammar is invalid. Seeing
-                            this type will result in a static assertion.
                no_action
                Placeholder type for use in entry/exit or transition behaviors, which
-                            does absolutely nothing.
                source_
                Generic object or function for the source state of a given transition:
                • as object: returns by reference the source state of a
+                                        events
                invalid_type
                Type returned by grammar parsers if the grammar is invalid. Seeing
+                            this type will result in a static assertion.
                no_action
                Placeholder type for use in entry/exit or transition behaviors, which
+                            does absolutely nothing.
                source_
                Generic object or function for the source state of a given transition:
                • as object: returns by reference the source state of a
                                         transition, usually to be used by another function (usually
                                         one created by MSM_EUML_METHOD or MSM_EUML_FUNCTION).
                  Example:
                                         
                  some_user_function_(source_)
                • as function: returns by reference the attribute passed as
                                         parameter.
                  Example:
-                                        
                  source_(m_counter)++
                target_
                Generic object or function for the target state of a given transition:
                • as object: returns by reference the target state of a
+                                        
                  source_(m_counter)++
                target_
                Generic object or function for the target state of a given transition:
                • as object: returns by reference the target state of a
                                         transition, usually to be used by another function (usually
                                         one created by MSM_EUML_METHOD or MSM_EUML_FUNCTION).
                  Example:
                                         
                  some_user_function_(target_)
                • as function: returns by reference the attribute passed as
                                         parameter.
                  Example:
-                                        
                  target_(m_counter)++
                state_
                Generic object or function for the state of a given entry / exit
+                                        
                target_(m_counter)++
                state_
                Generic object or function for the state of a given entry / exit
                             behavior. state_ means source_ while in the context of an exit behavior
                             and target_ in the context of an entry behavior:
                • as object: returns by reference the current state, usually
                                         to be used by another function (usually one created by
                                         MSM_EUML_METHOD or MSM_EUML_FUNCTION).
                  Example:
                                         
                  some_user_function_(state_) // calls some_user_function on the current state
                • as function: returns by reference the attribute passed as
                                         parameter.
                  Example:
-                                        
                  state_(m_counter)++
                event_
                Generic object or function for the event triggering a given transition
+                                        
                state_(m_counter)++
                event_
                Generic object or function for the event triggering a given transition
                             (valid in a transition behavior, as well as in state entry/exit behaviors):
                • as object: returns by reference the event of a transition,
                                         usually to be used by another function (usually one created
                                         by MSM_EUML_METHOD or MSM_EUML_FUNCTION).
                  Example:
                                         
                  some_user_function_(event_)
                • as function: returns by reference the attribute passed as
                                         parameter.
                  Example:
-                                        
                  event_(m_counter)++
                fsm_
                Generic object or function for the state machine containing a given transition:
                • as object: returns by reference the event of a transition,
+                                        
                  event_(m_counter)++
                fsm_
                Generic object or function for the state machine containing a given transition:
                • as object: returns by reference the event of a transition,
                                         usually to be used by another function (usually one created
                                         by MSM_EUML_METHOD or MSM_EUML_FUNCTION).
                  Example:
                                         
                  some_user_function_(fsm_)
                • as function: returns by reference the attribute passed as
                                         parameter.
                  Example:
-                                        
                  fsm_(m_counter)++
                substate_
                Generic object or function returning a state of a given state machine:
                • with 1 parameter: returns by reference the state passed as
+                                        
                  fsm_(m_counter)++
                substate_
                Generic object or function returning a state of a given state machine:
                • with 1 parameter: returns by reference the state passed as
                                         parameter, usually to be used by another function (usually
                                         one created by MSM_EUML_METHOD or MSM_EUML_FUNCTION).
                  Example:
                                         
                  some_user_function_(substate_(my_state))
                • with 2 parameters: returns by reference the state passed
@@ -544,46 +544,46 @@ ActionSequence := Action | (Action ',' Action)
                  Relevant operators are: +
                                         parameter, usually to be used by another function (usually
                                         one created by MSM_EUML_METHOD or MSM_EUML_FUNCTION). This
                                         makes sense when used in combination with attribute_.
                  Example (equivalent to the previous example):
-                                        
                  some_user_function_(substate_(my_state,fsm_))
                attribute_
                Generic object or function returning the attribute passed (by name) as
+                                        
                some_user_function_(substate_(my_state,fsm_))
                attribute_
                Generic object or function returning the attribute passed (by name) as
                             second parameter of the thing passed as first (a state, event or state
                             machine). Example: 
                
                             
                attribute_(substate_(my_state),cd_name_attribute)++
                
-                        
                True_
                Functor returning true for transition or state behaviors. Like all
+                        
                True_
                Functor returning true for transition or state behaviors. Like all
                             constants, only the functor form exists, so parenthesis are necessary.
                             Example:
                
                             
                if_then_(True_(),/* some action always called*/)
                
-                        
                False_
                Functor returning false for transition or state behaviors. Like all
+                        
                False_
                Functor returning false for transition or state behaviors. Like all
                             constants, only the functor form exists, so parenthesis are necessary.
                             Example:
                
                             
                if_then_(False_(),/* some action never called */)
                
-                        
                Int_<int value>
                Functor returning an integer value for transition or state behaviors.
+                        
                Int_<int value>
                Functor returning an integer value for transition or state behaviors.
                             Like all constants, only the functor form exists, so parenthesis are
                             necessary. Example:
                
                             
                target_(m_ringing_cpt) = Int_<RINGING_TIME>() // RINGING_TIME is a constant
                
-                        
                Char_<char value>
                Functor returning a char value for transition or state behaviors. Like
+                        
                Char_<char value>
                Functor returning a char value for transition or state behaviors. Like
                             all constants, only the functor form exists, so parenthesis are
                             necessary. Example:
                
                             
                // look for 'S' in event.m_song
 [string_find_(event_(m_song),Char_<'S'>(),Size_t_<0>()) != Npos_<string>()]
                
-                        
                Size_t_<size_t value>
                Functor returning a size_t value for transition or state behaviors.
+                        
                Size_t_<size_t value>
                Functor returning a size_t value for transition or state behaviors.
                             Like all constants, only the functor form exists, so parenthesis are
                             necessary. Example:
                
                             
                substr_(event_(m_song),Size_t_<1>()) // returns a substring of event.m_song
                
-                        
                String_ < mpl::string >
                Functor returning a string for transition or state behaviors. Like all
+                        
                String_ < mpl::string >
                Functor returning a string for transition or state behaviors. Like all
                             constants, only the functor form exists, so parenthesis are necessary.
                             Requires boost >= 1.40 for mpl::string.
                Example:
                
                             
                // adds "Let it be" to fsm.m_src_container
 push_back_(fsm_(m_src_container), String_<mpl::string<'Let','it ','be'> >())
                
-                        
                Predicate_ < some_stl_compatible_functor >
                This functor eUML-enables a STL functor (for use in an algorithm).
+                        
                Predicate_ < some_stl_compatible_functor >
                This functor eUML-enables a STL functor (for use in an algorithm).
                             This is necessary because all what is in the transition table must be a
                             eUML terminal.
                Example:
                //equivalent to: 
 //std::accumulate(fsm.m_vec.begin(),fsm.m_vec.end(),1,std::plus<int>())== 1
 accumulate_(begin_(fsm_(m_vec)),end_(fsm_(m_vec)),Int_<1>(),
-            Predicate_<std::plus<int> >()) == Int_<1>())
                process_
                This function sends an event to up to 4 state machines by calling
+            Predicate_<std::plus<int> >()) == Int_<1>())
                process_
                This function sends an event to up to 4 state machines by calling
                                 process_event on them:
                • process_(some_event) : processes an event in
                                         the current (containing) state machine.
                • process_(some_event [,fsm1...fsm4] ) :
                                         processes the same event in the 1-4 state machines passed as
-                                        argument.
                process2_
                This function sends an event to up to 3 state machines by calling
+                                        argument.
                process2_
                This function sends an event to up to 3 state machines by calling
                                 process_event on them and copy-constructing the event
                             from the data passed as second parameter:
                • process2_(some_event, some_data) : processes
                                         an event in the current (containing) state machine.
                • process2_(some_event, some_data [,fsm1...fsm3]
@@ -593,24 +593,24 @@ accumulate_(begin_(fsm_(m_vec)),end_(fsm_(m_vec)),Int_<1>(),
 // copy-constructed with event.m_song
 process2_(NotFound,event_(m_song))
                  
                         
                  With the following definitions:
                  BOOST_MSM_EUML_DECLARE_ATTRIBUTE(std::string,m_song)//declaration of m_song
-NotFound (const string& data) // copy-constructor of NotFound
                is_flag_
                This function tells if a flag is active by calling
+NotFound (const string& data) // copy-constructor of NotFound
                is_flag_
                This function tells if a flag is active by calling
                                 is_flag_active on the current state machine or one
                             passed as parameter:
                • is_flag_(some_flag) : calls
                                             is_flag_active on the current (containing)
                                         state machine.
                • is_flag_(some_flag, some_fsm) :calls
                                             is_flag_active on the state machine.passed
-                                        as argument.
                defer_
                This object defers the current event by calling
+                                        as argument.
                defer_
                This object defers the current event by calling
                                 defer_event on the current state machine.
-                            Example:
                Empty() + play() / defer_
                explicit_(submachine-name,state-name)
                Used as transition's target, causes an explicit entry into the given
+                            Example:
                Empty() + play() / defer_
                explicit_(submachine-name,state-name)
                Used as transition's target, causes an explicit entry into the given
                             state from the given submachine. Several explicit_ as targets, separated
                             by commas, means a fork. The state must have been declared as such using
-                            BOOST_MSM_EUML_EXPLICIT_ENTRY_STATE.
                entry_pt_(submachine-name,state-name)
                Used as transition's target from a containing state machine, causes
+                            BOOST_MSM_EUML_EXPLICIT_ENTRY_STATE.
                entry_pt_(submachine-name,state-name)
                Used as transition's target from a containing state machine, causes
                             submachine-name to be entered using the given entry pseudo-state. This
                             state must have been declared as pseudo entry using
-                            BOOST_MSM_EUML_ENTRY_STATE.
                exit_pt_(submachine-name,state-name)
                Used as transition's source from a containing state machine, causes
+                            BOOST_MSM_EUML_ENTRY_STATE.
                exit_pt_(submachine-name,state-name)
                Used as transition's source from a containing state machine, causes
                             submachine-name to be left using the given exit pseudo-state. This state
                             must have been declared as pseudo exit using
-                            BOOST_MSM_EUML_EXIT_STATE.
                MSM_EUML_FUNCTION
                This macro creates a eUML function and a functor for use with the
+                            BOOST_MSM_EUML_EXIT_STATE.
                MSM_EUML_FUNCTION
                This macro creates a eUML function and a functor for use with the
                             functor front-end, based on a free function:
                • first parameter: the name of the functor
                • second parameter: the underlying function
                • third parameter: the eUML function name
                • fourth parameter: the return type if used in a transition
                                         behavior
                • fifth parameter: the return type if used in a state
                                         behavior (entry/exit)
                 Note that the function itself can take up to 5
@@ -618,7 +618,7 @@ NotFound (const string& data) // copy-constructor of NotFound
                MSM_EUML_FUNCTION(BinarySearch_,std::binary_search,binary_search_,bool,bool)
                
                         
                Can be used like:
                
                             
                binary_search_(begin_(fsm_(m_var)),end_(fsm_(m_var)),Int_<9>())
                
-                        
                MSM_EUML_METHOD
                This macro creates a eUML function and a functor for use with the
+                        
                MSM_EUML_METHOD
                This macro creates a eUML function and a functor for use with the
                             functor front-end, based on a method:
                • first parameter: the name of the functor
                • second parameter: the underlying function
                • third parameter: the eUML function name
                • fourth parameter: the return type if used in a transition
                                         behavior
                • fifth parameter: the return type if used in a state
                                         behavior (entry/exit)
                 Note that the method itself can take up to 4 arguments
@@ -630,40 +630,40 @@ NotFound (const string& data) // copy-constructor of NotFound
                Can be used like:
                
                             
                Empty == Open + open_close / (close_drawer , activate_empty_(target_))
                
-                        
                BOOST_MSM_EUML_ACTION(action-instance-name)
                This macro declares a behavior type and a const instance for use in
+                        
                BOOST_MSM_EUML_ACTION(action-instance-name)
                This macro declares a behavior type and a const instance for use in
                             state or transition behaviors. The action implementation itself follows
                             the macro declaration, for example:
                BOOST_MSM_EUML_ACTION(good_disk_format)
 {
      template <class Fsm,class Evt,class SourceState,class TargetState>
      void/bool operator()(Evt const& evt,Fsm&,SourceState& ,TargetState& ){...}
-};
                BOOST_MSM_EUML_FLAG(flag-instance-name)
                This macro declares a flag type and a const instance for use in
-                            behaviors.
                BOOST_MSM_EUML_FLAG_NAME(flag-instance-name)
                This macro returns the name of the flag type generated by
+};
                BOOST_MSM_EUML_FLAG(flag-instance-name)
                This macro declares a flag type and a const instance for use in
+                            behaviors.
                BOOST_MSM_EUML_FLAG_NAME(flag-instance-name)
                This macro returns the name of the flag type generated by
                             BOOST_MSM_EUML_FLAG. You need this where the type is required (usually
-                            with the back-end method is_flag_active). For example:
                fsm.is_flag_active<BOOST_MSM_EUML_FLAG_NAME(CDLoaded)>()
                BOOST_MSM_EUML_DECLARE_ATTRIBUTE(event-type,event-name)
                This macro declares an attribute called event-name of type event-type.
+                            with the back-end method is_flag_active). For example:
                fsm.is_flag_active<BOOST_MSM_EUML_FLAG_NAME(CDLoaded)>()
                BOOST_MSM_EUML_DECLARE_ATTRIBUTE(event-type,event-name)
                This macro declares an attribute called event-name of type event-type.
                             This attribute can then be made part of an attribute list using
-                            BOOST_MSM_EUML_ATTRIBUTES.
                BOOST_MSM_EUML_ATTRIBUTES(attributes-expression,attributes-name)
                This macro declares an attribute list called attributes-name based on
+                            BOOST_MSM_EUML_ATTRIBUTES.
                BOOST_MSM_EUML_ATTRIBUTES(attributes-expression,attributes-name)
                This macro declares an attribute list called attributes-name based on
                             the expression as first argument. These attributes can then be made part
                             of an event using BOOST_MSM_EUML_EVENT_WITH_ATTRIBUTES, of a state as
                             3rd parameter of BOOST_MSM_EUML_STATE or of a state machine as 5th
                             parameter of BOOST_MSM_EUML_DECLARE_STATE_MACHINE.
                Attributes are added using left-shift, for example:
                // m_song is of type std::string
 BOOST_MSM_EUML_DECLARE_ATTRIBUTE(std::string,m_song)
 // contains one attribute, m_song
-BOOST_MSM_EUML_ATTRIBUTES((attributes_ << m_song ), FoundDef)
                BOOST_MSM_EUML_EVENT(event-instance name)
                This macro defines an event type (event-instance-name_helper) and
+BOOST_MSM_EUML_ATTRIBUTES((attributes_ << m_song ), FoundDef)
                BOOST_MSM_EUML_EVENT(event-instance name)
                This macro defines an event type (event-instance-name_helper) and
                             declares a const instance of this event type called event-instance-name
-                            for use in a transition table or state behaviors.
                BOOST_MSM_EUML_EVENT_WITH_ATTRIBUTES(event-instance-name,attributes)
                This macro defines an event type (event-instance-name_helper) and
+                            for use in a transition table or state behaviors.
                BOOST_MSM_EUML_EVENT_WITH_ATTRIBUTES(event-instance-name,attributes)
                This macro defines an event type (event-instance-name_helper) and
                             declares a const instance of this event type called event-instance-name
                             for use in a transition table or state behaviors. The event will have as
                             attributes the ones passed by the second argument:
                BOOST_MSM_EUML_EVENT_WITH_ATTRIBUTES(Found,FoundDef)
                         
                The created event instance supports operator()(attributes) so that
                             
                my_back_end.process_event(Found(some_string))
                
-                            is possible.
                BOOST_MSM_EUML_EVENT_NAME(event-instance-name)
                This macro returns the name of the event type generated by
+                            is possible.
                BOOST_MSM_EUML_EVENT_NAME(event-instance-name)
                This macro returns the name of the event type generated by
                             BOOST_MSM_EUML_EVENT or BOOST_MSM_EUML_EVENT_WITH_ATTRIBUTES. You need
                             this where the type is required (usually inside a back-end definition).
                             For example:
                
                             
                typedef msm::back::state_machine<Playing_,
 msm::back::ShallowHistory<mpl::vector<BOOST_MSM_EUML_EVENT_NAME(end_pause)
 > > > Playing_type;
                
-                        
                BOOST_MSM_EUML_STATE(build-expression,state-instance-name)
                This macro defines a state type (state-instance-name_helper) and
+                        
                BOOST_MSM_EUML_STATE(build-expression,state-instance-name)
                This macro defines a state type (state-instance-name_helper) and
                             declares a const instance of this state type called state-instance-name
                             for use in a transition table or state behaviors.
                There are several possibilitites for the expression syntax:
                • (): state without entry or exit action.
                • (Expr1): state with entry but no exit action.
                • (Expr1,Expr2): state with entry and exit action.
                • (Expr1,Expr2,Attributes): state with entry and exit
                                         action, defining some attributes.
                • (Expr1,Expr2,Attributes,Configure): state with entry and
@@ -672,7 +672,7 @@ msm::back::ShallowHistory<mpl::vector<BOOST_MSM_EUML_EVENT_NAME(end_pause)
                                         events).
                • (Expr1,Expr2,Attributes,Configure,Base): state with entry
                                         and exit action, defining some attributes, flags and
                                         deferred events (plain msm deferred events) and a
-                                        non-default base state (as defined in standard MSM).
                BOOST_MSM_EUML_INTERRUPT_STATE(build-expression,state-instance-name)
                This macro defines an interrupt state type
+                                        non-default base state (as defined in standard MSM).
                BOOST_MSM_EUML_INTERRUPT_STATE(build-expression,state-instance-name)
                This macro defines an interrupt state type
                             (state-instance-name_helper) and declares a const instance of this state
                             type called state-instance-name for use in a transition table or state
                             behaviors.
                There are several possibilitites for the expression syntax. In all of
@@ -689,7 +689,7 @@ msm::back::ShallowHistory<mpl::vector<BOOST_MSM_EUML_EVENT_NAME(end_pause)
                                         interrupt state with entry and exit action, defining some
                                         attributes, flags and deferred events (plain msm deferred
                                         events) and a non-default base state (as defined in standard
-                                        MSM).
                BOOST_MSM_EUML_TERMINATE_STATE(build-expression,state-instance-name)
                This macro defines a terminate pseudo-state type
+                                        MSM).
                BOOST_MSM_EUML_TERMINATE_STATE(build-expression,state-instance-name)
                This macro defines a terminate pseudo-state type
                             (state-instance-name_helper) and declares a const instance of this state
                             type called state-instance-name for use in a transition table or state
                             behaviors.
                There are several possibilitites for the expression syntax:
                • (): terminate pseudo-state without entry or exit
@@ -703,7 +703,7 @@ msm::back::ShallowHistory<mpl::vector<BOOST_MSM_EUML_EVENT_NAME(end_pause)
                                         pseudo-state with entry and exit action, defining some
                                         attributes, flags and deferred events (plain msm deferred
                                         events) and a non-default base state (as defined in standard
-                                        MSM).
                BOOST_MSM_EUML_EXIT_STATE(build-expression,state-instance-name)
                This macro defines an exit pseudo-state type
+                                        MSM).
                BOOST_MSM_EUML_EXIT_STATE(build-expression,state-instance-name)
                This macro defines an exit pseudo-state type
                             (state-instance-name_helper) and declares a const instance of this state
                             type called state-instance-name for use in a transition table or state
                             behaviors.
                There are several possibilitites for the expression syntax:
                • (forwarded_event):exit pseudo-state without entry or exit
@@ -719,7 +719,7 @@ msm::back::ShallowHistory<mpl::vector<BOOST_MSM_EUML_EVENT_NAME(end_pause)
                                         attributes, flags and deferred events (plain msm deferred
                                         events) and a non-default base state (as defined in standard
                                         MSM).
                Note that the forwarded_event must be constructible from the event
-                            sent by the submachine containing the exit point.
                BOOST_MSM_EUML_ENTRY_STATE(int
+                            sent by the submachine containing the exit point.
                BOOST_MSM_EUML_ENTRY_STATE(int
                             region-index,build-expression,state-instance-name)
                This macro defines an entry pseudo-state type
                             (state-instance-name_helper) and declares a const instance of this state
                             type called state-instance-name for use in a transition table or state
@@ -734,7 +734,7 @@ msm::back::ShallowHistory<mpl::vector<BOOST_MSM_EUML_EVENT_NAME(end_pause)
                                         pseudo-state with entry and exit action, defining some
                                         attributes, flags and deferred events (plain msm deferred
                                         events) and a non-default base state (as defined in standard
-                                        MSM).
                BOOST_MSM_EUML_EXPLICIT_ENTRY_STATE(int
+                                        MSM).
                BOOST_MSM_EUML_EXPLICIT_ENTRY_STATE(int
                             region-index,build-expression,state-instance-name)
                This macro defines a submachine's substate type
                             (state-instance-name_helper), which can be explicitly entered and also
                             declares a const instance of this state type called state-instance-name
@@ -745,28 +745,28 @@ msm::back::ShallowHistory<mpl::vector<BOOST_MSM_EUML_EVENT_NAME(end_pause)
                                         events).
              • (Expr1,Expr2,Attributes,Configure,Base): state with entry
                                         and exit action, defining some attributes, flags and
                                         deferred events (plain msm deferred events) and a
-                                        non-default base state (as defined in standard MSM).
                • BOOST_MSM_EUML_STATE_NAME(state-instance-name)
                This macro returns the name of the state type generated by
+                                        non-default base state (as defined in standard MSM).
                BOOST_MSM_EUML_STATE_NAME(state-instance-name)
                This macro returns the name of the state type generated by
                             BOOST_MSM_EUML_STATE or other state macros. You need this where the type
                             is required (usually using a backend function). For example:
                
                             
                fsm.get_state<BOOST_MSM_EUML_STATE_NAME(StringFind)&>().some_state_function();
                
-                        
                BOOST_MSM_EUML_DECLARE_STATE(build-expression,state-instance-name)
                Like BOOST_MSM_EUML_STATE but does not provide an instance, simply a
-                            type declaration.
                BOOST_MSM_EUML_DECLARE_INTERRUPT_STATE(build-expression,state-instance-name)
                Like BOOST_MSM_EUML_INTERRUPT_STATE but does not provide an instance,
-                            simply a type declaration.
                BOOST_MSM_EUML_DECLARE_TERMINATE_STATE(build-expression,state-instance-name)
                Like BOOST_MSM_EUML_TERMINATE_STATE but does not provide an instance,
-                            simply a type declaration.
                BOOST_MSM_EUML_DECLARE_EXIT_STATE(build-expression,state-instance-name)
                Like BOOST_MSM_EUML_EXIT_STATE but does not provide an instance,
-                            simply a type declaration.
                BOOST_MSM_EUML_DECLARE_ENTRY_STATE(int
+                        
                BOOST_MSM_EUML_DECLARE_STATE(build-expression,state-instance-name)
                Like BOOST_MSM_EUML_STATE but does not provide an instance, simply a
+                            type declaration.
                BOOST_MSM_EUML_DECLARE_INTERRUPT_STATE(build-expression,state-instance-name)
                Like BOOST_MSM_EUML_INTERRUPT_STATE but does not provide an instance,
+                            simply a type declaration.
                BOOST_MSM_EUML_DECLARE_TERMINATE_STATE(build-expression,state-instance-name)
                Like BOOST_MSM_EUML_TERMINATE_STATE but does not provide an instance,
+                            simply a type declaration.
                BOOST_MSM_EUML_DECLARE_EXIT_STATE(build-expression,state-instance-name)
                Like BOOST_MSM_EUML_EXIT_STATE but does not provide an instance,
+                            simply a type declaration.
                BOOST_MSM_EUML_DECLARE_ENTRY_STATE(int
                             region-index,build-expression,state-instance-name)
                Like BOOST_MSM_EUML_ENTRY_STATE but does not provide an instance,
-                            simply a type declaration.
                BOOST_MSM_EUML_DECLARE_EXPLICIT_ENTRY_STATE(int
+                            simply a type declaration.
                BOOST_MSM_EUML_DECLARE_EXPLICIT_ENTRY_STATE(int
                             region-index,build-expression,state-instance-name)
                Like BOOST_MSM_EUML_EXPLICIT_ENTRY_STATE but does not provide an
-                            instance, simply a type declaration.
                BOOST_MSM_EUML_TRANSITION_TABLE(expression,
+                            instance, simply a type declaration.
                BOOST_MSM_EUML_TRANSITION_TABLE(expression,
                             table-instance-name)
                This macro declares a transition table type and also declares a const
                             instance of the table which can then be used in a state machine
                             declaration (see BOOST_MSM_EUML_DECLARE_STATE_MACHINE).The expression
                             must follow the transition
-                                table grammar.
                BOOST_MSM_EUML_DECLARE_TRANSITION_TABLE(iexpression,table-instance-name)
                Like BOOST_MSM_EUML_TRANSITION_TABLE but does not provide an instance,
-                            simply a type declaration.
                BOOST_MSM_EUML_INTERNAL_TRANSITION_TABLE(expression,
+                                table grammar.
                BOOST_MSM_EUML_DECLARE_TRANSITION_TABLE(iexpression,table-instance-name)
                Like BOOST_MSM_EUML_TRANSITION_TABLE but does not provide an instance,
+                            simply a type declaration.
                BOOST_MSM_EUML_INTERNAL_TRANSITION_TABLE(expression,
                             table-instance-name)
                This macro declares a transition table type and also declares a const
                             instance of the table.The expression must follow the transition table
-                                grammar. For the moment, this macro is not used.
                BOOST_MSM_EUML_DECLARE_INTERNAL_TRANSITION_TABLE(iexpression,table-instance-name)
                Like BOOST_MSM_EUML_TRANSITION_TABLE but does not provide an instance,
+                                grammar. For the moment, this macro is not used.
                BOOST_MSM_EUML_DECLARE_INTERNAL_TRANSITION_TABLE(iexpression,table-instance-name)
                Like BOOST_MSM_EUML_TRANSITION_TABLE but does not provide an instance,
                             simply a type declaration. This is currently the only way to declare an
                             internal transition table with eUML. For example:
                BOOST_MSM_EUML_DECLARE_STATE((Open_Entry,Open_Exit),Open_def)
 struct Open_impl : public Open_def
diff --git a/doc/PDF/examples/CompositeTutorialWithEumlTable.cpp b/doc/PDF/examples/CompositeTutorialWithEumlTable.cpp
index 7783d2c..7fce5de 100644
--- a/doc/PDF/examples/CompositeTutorialWithEumlTable.cpp
+++ b/doc/PDF/examples/CompositeTutorialWithEumlTable.cpp
@@ -112,11 +112,7 @@ namespace
 
     };
     // Playing Submachine back-end
-    typedef boost::msm::back::state_machine Playing_helper;
-    struct Playing_impl : public Playing_helper,
-                          public msm::front::euml::euml_state
-    {
-    };
+    typedef boost::msm::back::state_machine Playing_impl;
 
     // state not defining any entry or exit
     struct Paused_impl : public msm::front::state<> , public msm::front::euml::euml_state
diff --git a/doc/PDF/msm.pdf b/doc/PDF/msm.pdf
index 491b9bf..9d70e62 100644
Binary files a/doc/PDF/msm.pdf and b/doc/PDF/msm.pdf differ
diff --git a/doc/images/Defer.jpg b/doc/images/Defer.jpg
new file mode 100644
index 0000000..44381d8
Binary files /dev/null and b/doc/images/Defer.jpg differ
diff --git a/doc/src/msm.xml b/doc/src/msm.xml
index 65c9153..8824482 100644
--- a/doc/src/msm.xml
+++ b/doc/src/msm.xml
@@ -1890,7 +1890,7 @@ Stopped  == Empty   + cd_detected [good_disk_format] / store_cd_info
                         without any syntactic noise at all.
                 
                 
-                    A simple example: rewriting only our transition table
+                    A simple example: rewriting only our transition table 
                     As an introduction to eUML, we will rewrite our tutorial's transition
                         table using eUML. This will require two or three changes, depending on the compiler:
                             
@@ -1908,24 +1908,21 @@ Stopped  == Empty   + cd_detected [good_disk_format] / store_cd_info
                     We now can write the transition table like just shown, using
                         BOOST_MSM_EUML_DECLARE_TRANSITION_TABLE instead of
                         BOOST_MSM_EUML_TRANSITION_TABLE. The implementation is pretty
-                        straightforward.
-                    The composite implementation is slightly trickier because the submachine
-                        has to be a msm::back::state_machine and a msm::front::euml::state. For
-                        example:
+                            xlink:href="examples/SimpleTutorialWithEumlTable.cpp"
+                            >implementation is pretty straightforward. The only required
+                        addition is the need to declare a variable for each state or add parenses (a
+                        default-constructor call) in the transition table.
+                    The 
+                      composite implementation is also natural:
                     // front-end like always
-struct front_end : public boost::msm::front::state_machine_def<front_end>
+struct sub_front_end : public boost::msm::front::state_machine_def<sub_front_end>
 {
 ...
 };
 // back-end like always
-typedef boost::msm::back::state_machine<front_end> back_end;
-// this is new: make the submachine a eUML type
-struct submachine : public back_end,
-                    public boost::msm::front::euml::euml_state<back_end>
-{
-};
+typedef boost::msm::back::state_machine<sub_front_end> sub_back_end;
+
+sub_back_end const sub; // sub can be used in a transition table.
                     Unfortunately, there is a bug with VC, which appears from time to time and
                         causes in a stack overflow. If you get a warning that the program is
                         recursive on all paths, revert to either standard eUML or another front-end
@@ -3925,6 +3922,40 @@ typename ::boost::enable_if<
         
         
             Version history
+            
+                From V2.22 to V2.23 (Boost 1.50)
+                
+                    
+                        
+                             eUML : better syntax
+                                for front-ends defined with eUML as transititon table only. Caution:
+                                Breaking Change!
+                        
+                        
+                            Bugfix: graph building was only working if
+                                    initial_state defined as a sequence
+                        
+                        
+                            Bugfix: flags defined for a Terminate or Interrupt state do not
+                                break the blocking function of these states any more.
+                        
+                        
+                            Bugfix: multiple deferred events from several regions were not
+                                working in every case.
+                        
+                        
+                            Bugfix: visitor was passed by value to submachines.
+                        
+                        
+                            Bugfix: no_transition was not called for submachines who send an
+                                event to themselves.
+                        
+                        
+                            Fixed warnings with gcc
+                        
+                    
+                
+            
             
                 From V2.21 to V2.22 (Boost 1.48)