Off the top of my head, how about the functor Else_ below? Else_ <Guard1, Guard2, Guard3, ... >
For else, we can use the fact that msm tries guards from the bottom of the table to the top:
// else clause Row< state1, ev, state2, none, none>, // if clause Row< state1, ev, state2, none, Or_<...> > // more if clauses ...
Fantastic! This has 2 advantages and 1 disadvantage.
Advantages: One is simple enough. The other is good performance. It doesn't need evaluating the guard functor twice. I was about to consider how to cache the functor's result.
Disadvantage: As you might expect, the evaluating direction is opposite of my intuition.
Are there any reasons of this implementation?
There are. It's an implementation detail which dates back to the early phases of the library (start + 3 months). The reason is that msm adds, for performance, rows for submachines at the end of the table (one for every event found in the submachine), then starts processing from the bottom to give these rows a higher priority (UML rule). At the same time, the library also uses the table to generate state ids (http://svn.boost.org/svn/boost/trunk/libs/msm/doc/HTML/ch06s03.html). I could do the opposite (extra rows at the beginning) but it'd be pretty hard to guess after this what the state id you get in no_transition means (it's already hard enough to explain the current order, imagine if I had to explain you have to count in reverse order...). And as the else feature is not in the Standard, it seemed ok. In these early phases I didn't have, like now, different steps of transition table processing. This old decision could deserve some revisiting, but: - there are a few corner cases which could make a change pretty tricky (pseudo entry/exit states) - some people already use the current implementation state, so it'd break their code, I'd need some compile-time configuration, which would get hidden deep in the already big doc. The default would still be the current order.
Modifying to the opposite direction is easy?
Unfortunately not, so considering the gain and the time it'd cost, it's unlikely to change until I have nothing else to implement in the library, which could take some time ;-) Regards, Christophe