Re: [Boost-users] Meta State Machine PseudoExit transitions

Subject: Re: [Boost-users] Meta State Machine PseudoExit transitions
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2011-06-29 17:07:56

> Hello,
>
> I'm trying to implement a PseudoExitState in my boost meta state
> machine. This is the situation: http://i55.tinypic.com/2a83yar.png.
> Currently, when going from Transport to either Situation A or B, it
> throws an "no_transition" in the SubState for the "convertible event"
> needed by the PseudoExit state. (This is event6 in the example
> described below)
>
> According to the documentation
> (http://www.boost.org/doc/libs/1_46_1/libs/msm/doc/HTML/ch03s02.html#d0e930)
> and the corresponding example, there should be some kind of transition
> triggered by "event6" from SubState2 to Substate1 (see
> http://www.boost.org/doc/libs/1_46_1/libs/msm/doc/HTML/examples/DirectEntryTutorial.cpp,
> in the transition table for SubFsm2). I don't see an arrow in the
> state diagram between SubState2 and SubState1, nor can I figure out
> why I would want such a transition.

Hi,

the missing arrow has just been reported (today) to me and I just fixed it 
(in the trunk)
It is irrelevant in your case, that's why it wasn't in the diagram. It's 
just a transition which happens to be triggered by event6.

> In my SubState's transition table, I have defined the transition from
> Transport to PseudoExit1 and 2:
>
> g_row< Transport  , Sensor         , Exit1                     ,
> &SubFront::SDownstreamCheck   >,
> g_row< Transport  , Sensor         , Exit2                     ,
> &SubFront::SDownstreamNoCheck >
>
> and in the TopState from PseudoExit1 and 2 to SituationA and B:
>
> _row< Sub::exit_pt< SubFront::Exit1 > , TransportDone    , SituationA >,
> _row< Sub::exit_pt< SubFront::Exit2 > , TransportDone    , SituationB >,
>
> So do i have to handle an "TransportDone" event in the SubState? And
> what are my Start and End states?
> I would appreciate your help :)

It depends what you want to do. The UML Standard actually only foresees the 
possibility to move into a pseudo exit triggered by an event (in your case 
Sensor) and exit it with this exact event. If it's what you want, no 
problem, replace TransportDone by Sensor in your outer transitions and it 
will work. Just don't forget to indicate it in the pseudo exit definition:

struct Exit1 : public msm::front::exit_pseudo_state<Sensor> // Pseudo exit 
will forward Sensor events

MSM also offers you the non-standard possibility to have another event 
constructed and forwarded by the pseudo exit. The condition is that this 
outer event can be constructed from the inner one. So TransportDone could 
be, for example:

    struct TransportDone
    {
        TransportDone(){}
        // copy construct from any other event
        template <class Event>
        TransportDone(Event const&){}
    };

Now you should have no more calls to no_transition.

Unfortunately, to my surprise, it has been reported shortly that the 
compiler does not throw an error if the copy-constructor is forgotten (which 
I think to remember once was the case). I'll try to find a way to force him 
to do so to avoid this easy-to-make mistake.

> Best Regards,
> Johan

HTH,
Christophe