Boost logo

Boost :

Subject: Re: [boost] [msm]exit pseudo state and event
From: Takatoshi Kondo (kondo_at_[hidden])
Date: 2011-07-08 06:12:17

On Wed, 6 Jul 2011 23:09:37 +0200
"Christophe Henry" <christophe.j.henry_at_[hidden]> wrote:

> >> I think I'll need your example to understand this question.
> >> Generally, my opinion is that I want the weakest dependency I can get
> >> away
> >> with. And a dependency to a template method of an event seems to me a
> >> weaker
> >> one than a dependency to a submachine class. Both ways because the
> >> submachine would also have to make some assumptions about the main
> >> machine's
> >> behaviour.
> >
> > In the case of event parameter, I completely agree with you.
> > But I'm not sure how to propagate the sub-machine's action result
> > to main-machine without adding the interface to sub-machine.
> >
> > I have two ideas.
> > 1. Using the internal transition. (See 13_PropagateActionResult.cpp
> > Event2)
> > Can I call the member function "process_event" inside the action
> > functor??
> > (See Line 69)
> Yes. I didn't try your example out but it looks good.

I think it's a typical pattern that propagate sub-machine's information
to outside state machine via event mechanism.

> > More generally, does the msm provide interfaces that send events to
> > their own state machine?
> Sure. That's one of the main reasons to pass the fsm as parameter to the
> action.
> > 2. Add the mutable variable to event classes, and modify the variable in
> > action functor.
> > I think it is ugly.
> I agree :)
> > If there are no good ideas to do that, your approach solves only
> > event parameter. I think it's too partial.
> >
> > I hope 1 is OK.
> > Or do you have any better ideas?
> What you are doing should work without problems.

At first, I was not sure it is correct or not
that calling process_event recursively.

process_event() -> operator()() -> process_event()

But you pointed out it's no problem.
I can use the msm mechanism flexibly!

> As a side note, I like the Guard1 / Not_<Guard1> construct. It's the best
> way to ensure that guards are mutually exclusive.

I think that your euml functor is also useful outside of euml as DESL.

The functor Not_ is suitable for "else".
But if we have much more guards, We have to use Or_ functor like this.
msme::Not_< msme::Or_< msme::Or_<Guard1, Guard2>, Guard3> >

Off the top of my head, how about the functor Else_ below?
Else_ <Guard1, Guard2, Guard3, ... >

> Regards,
> Christophe


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