Subject: Re: [boost] [msm] orthogonal region and event consume
From: Takatoshi Kondo (redboltz_at_[hidden])
Date: 2012-05-29 00:47:44
I had gotten an incoming event confused with an outgoing event of
entry pseudo state.
Please ignore my patch.
On Sat, May 26, 2012 at 11:43 PM, Takatoshi Kondo <redboltz_at_[hidden]> wrote:
> I wrote a patch.
> If an event that corresponds to the transition from an entry pseudo
> state is not equal to boost::msm::front::none,
> then do self->process_event(evt.m_event);
> Else doesn't do it.
> This patch brings dependency that from msm::back to msm::front. If it
> is not suitable, msm::front::none may move to msm/common.hpp.
> On Sat, May 26, 2012 at 3:40 PM, Takatoshi Kondo <redboltz_at_[hidden]> wrote:
>> I analyzed this problem deeply. It doesn't relate to orthogonal regions.
>> My understanding is that Boost.Msm requires the same event for
>> transitions that to entry pseudo state and from entry pseudo state.
>> So, in simple_entry.png(attached diagram), the transition from Entry1
>> requires Event1.
>> But this requirement is sometimes problematic. Because submachines
>> sometimes shouldn't know the outside information such as Event1. So, I
>> chose msm::front::none instead of Event1 (entry_pseudo_event.cpp).
>> msm::front::none event approach has two problems. One is preserving
>> outer event. And then the event is handled similar as the deferred
>> event. The other is there is no way to get the outer event in the
>> I believe that the former should be fixed. But I found another solution.
>> See the entry_pseudo_event_template.cpp.
>> The event that corresponds to the transition from the entry pseudo
>> state is injected as a template parameter. So, submachine doesn't need
>> to know the Event1.
>> This approach solves the both above problems.
>> On Fri, May 25, 2012 at 5:48 PM, Takatoshi Kondo <redboltz_at_[hidden]> wrote:
>>> Hello Christophe,
>>> I'm using Boost.MSM version 1.49.0. I bumped on a suspicious behavior.
>>> See the attached diagram and code. When Event1 occurs in State1,
>>> Action1 is invoked.
>>> I think the event isn't consumed correctly.
>>> If the transition from State1 to State2 connect State2 directly
>>> instead of Entry1, the event seems to be consumed.
>>> What do you think?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk