Regarding my boost::variant: It is used to compose 44 different event types. Additionally this event type is passed as template parameter to the stl::queue <> container , which is used as global event queue for all my state machines (submachines). So each state of a submachine can put in a corresponding event to that special/global event queue. Afterwards my "event dispatcher" gets from the global event queue the latest event and forwards it to the process_event method. I use the approach with the global event queue due to the fact, that the submachines in boost.msm are not able to put events into the event queue of the parent state machine (enclosing state machine). (We already talk about this almost two month ago if you remember...).
Hi, wait, I never said anything like "the submachines in boost.msm are not able to put events into the event queue of the parent state machine"!!! All I said is that they don't know their parents. Actually they can and there are 2 ways: - the UML conform. Use a pseudo exit, this will move the flow of control to the parent fsm, in the out transition you can call process_event, which will post... in the parent fsm queue. - C++ tricks: after creating the parent fsm, which also creates all submachines, you can pass to the submachine a pointer to the parent on which you can call process_event. You will have to forward-declare the parent fsm, but hell, it's still doable. Alternatively, you can use an event and pass the pointer in the event, or more cleanly, to avoid cycles, which are a bad design, pass instead a boost::function or type_erasure, which calls map to a process_event on the parent. I don't see a reason for a global queue (global is such a bad word...). Cheers, Christophe