Boost logo

Boost :

Subject: Re: [boost] [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-02-03 14:11:42

Le 02/02/2016 22:12, Krzysztof Jusiak a écrit :
> On Tue, Feb 2, 2016 at 6:19 PM, Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]> wrote:
>> Le 01/02/2016 11:57, Kris a écrit :
>> Hi, IIUC you are proposing a 3rd MSM library in Boost, and you don't
>> pretend to make it a sub-library of Boost.MSM. If I'm right, I suggest you
>> to rename the namespace to msm_lite or whatever you find more appropriated.
> Fair point, thanks for pointing it out. It's a valid concern. I have
> nothing against changing the namespace/name as 'msm-lite' is just a working
> title either way. Not sure what the best name should be tho?
Well, you would need to choose a name ;-)
>> Well these are already quite a few features. I have not see local
>> transitions (different from internal transitions).
> Yea interna(local) transitions are supported. Example here ->
Internal and local transitions are not the same. How do you make
syntactically the difference. I've not see and reference to local
> Please could you point me if you support choice points?
> While choice points are unavoidable in graphical UML, I find it not very
>> useful while writing MSM in C++ as I prefer to do it using if or switch.
>> However having a transition table that can have only one next-state by
>> transition disable this possibility. I use to have a transition table with
>> a transition that has an action_nextstate that do the action and returns
>> the nextstate of the transition.
>> |"s2"_s + event<e2> [ guard ] / action_nextstate This avoids the storage
>> of local variable on the MSM data context. |
>> Have you considered this possibility?
> Interesting idea, can you elaborate please as I'm not sure whether I follow
> the idea with the action_nextstate?
> If it comes to the choice points, I guess the easier way is just to have
> multiple transitions from the same state?
> make_transition_table(
> s1 -> s2 + e2 [some_guard1 && some_guard2] / action1
> , s1 -> s3 + e2 [other_guard] / action2
> , s1 + e2 / action3
> );
> would be the same as
> if (e2) {
> if (some_guard1 && some_guard2) {
> action1;
> change_state_to(s2);
> } else if(other_guard) {
> action2;
> change_state_to(s3);
> } else {
> action3;
> }
> }
This is almost the idea. But the use case is the followings, sorry I
will use the src + evt / act = dst notation

     s0 + e / action0 -> cp
     cp [some_guard1] / action1 -> s1
     cp [else] / action2 -> s2

With action-next-state transition could be

      s0 + e / action_nextstate

where action_nextstate is

auto action_nextstate = [](auto const& evt) {
     if (some_guard1) {
         next_state(s1); // You could also return a state if there is a
type that can store any state of the state machine.
     } else {

Note that these action-nextstate could define some local variables in
action0 that can be used in some_guard1 and in action1 and action2 .

The uml transition schema forces to store these local variable on the
state machine context (or a state context if supported), which is less
than optimal. This is needed because there is no way to share variables
between the action0, some_guard1 and in action1 and action2. In addition
action1 and action2 have no access to the event e, as only the action0
has it as parameter.

Do you think that this kind of transitions goes against the UML semantics?


Boost list run by bdawes at, gregod at, cpdaniel at, john at