Hi Barend, Sorry that I didn't have time to address earlier the questions in your review.

I would like to see a connection with Boost.Graph (I mean, see it in an example or so, not within the kernel), to see what I'm doing with all those transitions; I asked this on the list and this is possible, good.

It is a good point and I'll try to provide this, at least for simple state machines.

1) the struct "Row" is written with a capital, this is unusual within Boost. Words with a capital are normally template parameters. I understand why it is done (there was already a row without a capital in Msm 1.1), but I think it could have been solved differently (for example: "transition", or if that is too long "tr" which could stand for transition row or table row). I don't like to see Row where I expect to see a normal classname.

Conventions are always hard to define. I usually try to follow the following convention: - rows are usually not capitalized (a_row, g_row...) - except the row working with functors, like Row - eUML functors are also capitalized and finish with an underscore. - eUML functions are not capitalized and finish with an underscore. This tries to match the phoenix syntax. This allows differentiation between functors/non functors. I found this system practical but would not mind changing it if required.

The capitals are also used in the documentation and samples (struct Empty) but there I've less problems with it. Maybe use of Capitals for states is a state machine convention

Yes, it is a common habit in UML to capitalize state names (though I am not aware of any written rules).

I noticed different conventions in the source files. Many template parameters are completely capitalized. I had done the same thing, earlier, but was hinted that this is unusual as well. Just a matter of style (as long as library users normally don't see it, it is less important)

Yes, while the user doesn't see it, it is not very beautiful so I'll change this.

2) the class state_machine is quite long (in lines of code), containing several sub-structs which maybe (don't know) could be moved to a separate source file (detail).

Yes, it became quite big, you're right. It's quite practical for me to have functions and helpers at the same place but some parts could be separated.

You have to call p.start() manually

Yes. Calling start() will move the machine in its initial state and call on_entry on the machine and the initial state. You have to call it explicitly because sometimes you simply don't want on_entry to be called at the creation of the state machine.

Thanks for submitting this excellent library.

I'm happy that you like it. Thanks for the great work you put on the review. Regards, Christophe