...

Now it's proven that the concepts of the MPL book were right, that it was indeed possible to implement at least as much as statechart with metaprogramming techniques. That this wasn't evident, as shown here (http://lists.boost.org/Archives/boost/2005/03/81853.php).

For the record, back in 2005 I only expressed the opinion that it's not possible to implement a purely meta-programming-based FSM framework that supports both multi-TU machines and orthogonal regions. This should be obvious from the context quoted in the linked message.

I'm happy that you offer to clarify your thoughts because I'm afraid it isn't that obvious to me. You brought 2 reasons for this impossibility: 1. Automatic entry/exit. You answer that "With separate FSMs you'd have to manage this yourself". 2. Automatic event dispatch. You answer that "Again, with separate FSMs you'd have to do that yourself (dispatch to first FSM and if that didn't consume the event, dispatch to second FSM and so on)." Your point was that these 2 cases would have to be managed manually by the user and I fail to see what this has to do with multiple-TUs. Could you please explain this as it still seems unclear to me? Your answer was not about compile-time or recompiling if the structure of a region or separate FSM was changed, which would have been another issue and I would perfectly understand and accept this argument. What I understood from your post is that a full-metaprogramming fsm would not manage these 2 points because of some statechart-specific multiple-TU considerations, and I'd be grateful if you could explain them to me.

IIUC then MSM does not support multi-TU FSMs and you have so far not expressed any plans to support them, right?

I fail to see the difference with Statechart except on the amount of metaprogramming done. Please help me on that one, if I changed in Statechart the reactions typedef in the submachine and thus the submachine header, it would be, from a recompiling perspective, the same result as a full-metaprogramming fsm, right? If this really only is a difference in compile-time, I think this has already been discussed. To multiple TUs with MSM: An application is made of a fsm structure and lots more of user code. This user code can well be in another TU. The metaprogramming in the top-level fsm needs the header of a sub-fsm in order to let the compiler do its job, which is probably also what Statechart does or am I missing something? Reading again the explanation in Statechart's doc (http://www.boost.org/doc/libs/1_40_0/libs/statechart/doc/tutorial.html#Sprea...), I found in Camera.cpp: #include "Shooting.hpp" Which increases my confusion. It seems that Statechart's top-level fsm also needs the submachine header, which seems to make the multiple-TU point moot. Recompiling is another issue, which you didn't mention at that time (though it would have been a valid one), so please allow me to discuss it already now as it's likely that you'll bring this one next. By moving your submachines' application code into different TUs, you'll gain some compile-time if the submachine actions or application code also would cause long compile-times. You'll also gain that a change in a sub-fsm will not cause all to recompile but only the TUs of this fsm and the top-level one. The fact that I put all my submachines into one header doesn't force you to do the same. So yes, you probably can't spread the library metaprogramming work around different TUs, but you can full well spread the application work. Depending of how much this is, it can reduce your compile-time or be not visible. Again, what is concretely the difference with Statechart? Christophe