Hi all, Looks like there was a fair bit of discussion ;-) I'll try to give my take on the many discussed points. Jeffrey Bosboom wrote:

But I think this concern can be addressed if there is a documentation page that compares the libraries that is included in (or linked from) both libraries' documentation. This would make it much easier for a user to choose one or the other without having to read the full documentation for each.

This sounds like a good idea to me. Not everybody followed the review. Andrew Venikov wrote:

I think an even better example would be map and hash_map. They serve almost identical purpose but using totally different techniques. The user of stl is expected to understand the differences and chose the appropriate container. Why not do the same with SC and MSM?

Yes, we should really write a page explaining the trade-offs. David Bergman wrote:

I would even have welcomed some macros that introduce the state declarations for simplistic states, from that transition table expression.

There is something like this in eUML (on compilers with native typeof). Is this ok for you? typedef BOOST_TYPEOF(build_state( )) Paused; I can of course also add a macro for other compilers. David Bergman wrote:

Well, well, I seem to be the only one caring about this, and MSM sure is a fine library, so I say 'welcome metamagical states!'. NOTE: no, this was not a formal review ;-)

I would welcome a formal review though. It'd help the review manager make a decision ;-) Jeffrey Bosboom wrote:

Decide whether MSM should be included or not on its own merits. If so, then MSM makes Boost better; we shouldn't be so concerned with being perfect that we lose the opportunity to be better.

I agree. We should always decide on a library's merit and then see how to handle it. It'd be sad to lose an opprtunity to make boost more valuable on organisatory grounds. This doesn't apply only to MSM. David Bergman wrote:

You have a good point there. Although I would rather have seen the MSM guys collaborate with the Statechart guys on making Statechart easier to use (especially the expression of the transition table) and/or more performant, though. If that would have led to a combined Statechart 2.0 (analogous to Spirit 2.0) in a year, I would wait.

Merging would be quite hard. While both libraries seem to have almost the same interface, scratching the surface will show many differences. The reason is that both libraries follow a pretty different philosophy and use different techniques. The best which might be achieveable would be a new front-end in MSM trying to match as much as possible SC's front-end. It would probably work for simple state machines. It might even work for composites. I'm not expert enough in Statechart to tell if more is possible. And the question is if someone would ever need this. You would still get the compiler limitations (and maybe add some more due to the added metaprogramming) and not all of SC's features. Why to use it then? However, if someone is willing to take this task on, I'd be ready to help. Ideally we would have to do the same in Statechart for one of MSM's front-ends. Sounds like a lot of work. Christophe