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-17 12:46:19
Le 17/02/2016 16:20, Kris a Ã©crit :
> On Tue, Feb 16, 2016 at 9:50 PM, Vicente Botet [via Boost] <
> ml-node+s2283326n4683550h69_at_[hidden]> wrote:
>> Le 16/02/2016 17:44, Krzysztof Jusiak a Ã©crit :
>> I would assume following order according to the spec + a bit of
>>> 1. guard [to enable transition]
>>> 2. exit src state
>>> 3. actions...
>>> 4. CHANGE THE STATE TO DST HERE?
>>> 5. entry dst state
>> I agree. It was evident to me, but I can not point to any wording.
> Great to hear that. However, above sequence makes exception handling a bit
> harder as
> with guards we haven't left the src state but with actions we started the
> exit already.
> 1. When exception happens in a guard
> * src state is unchanged
> 2. When exception happens in an action
> * src state is exited
> Moreover, following below sequence
> 3. actions...
> 4. CHANGE THE STATE TO DST HERE?
> makes it harder to process internal events
> "src"_s + event / process_event(other_event) = "dst"_s
> , "src"_s + other_event = X // most likely, should be this one as we
> haven't changed the state yet?
> , "dst"_s + other_event = X
> and, therefore, maybe it's better to have it the other way around?
> 3. CHANGE THE STATE TO DST HERE?
> 4. actions...
I have never used process_event in an action on the same state machine
(You are re-entering the state machine :( ). The single think you can do
is to post it (push in a queue) or call process_event in another state
machine. However you must ensure the there are no cycles. The
asynchronous way avoids always the possible cycles.
In some projects I have defined a hierarchy of state machines and the
upper layer state machines use synchronous communication to communicate
to lower state machines and the reverse, lower layer use always
asynchronous communication with upper layer state machines (half
There are 3 features that I'm missing in UML state machines that I found
in SDL . Maybe these features have no sense with synchronous state
* Procedures that can contain states. The difference with nested states
is that procedures are stack based and return to the point of call when
the procedure terminates. You can reuse a procedure inside a state
machine several times of course.
* Synchronous Remote Procedures that allows to do a call/replay at once.
This avoids the use of wait states on which the every other event tan
the replay is deferred.
* Synchronous Remote Variables that allows to read a remote variable.The
same here; but just to query for the value of a remote variable.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk