Re: [Boost-users] [statechart] forward_event()

Subject: Re: [Boost-users] [statechart] forward_event()
From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2009-10-12 11:17:44

> Now I get it. This is, was I saw in the debugger. OK. It's a little messy 
> for me. I'm afraid that there is no way, to change this. I'm thinking 
> about a special reaction in these orthogonal states to route the event 
> "sidewards" instead of downwards. Any chance?

UML is quite clear on the order how reactions are checked (always from 
the/an innermost state outward). Now, if we come to the conclusion that your 
use-case is sufficiently common *and* if there is no easier way to achieve 
the behavior you want, I might consider adding such a beast. But again, 
that'll be 1.42 *at* *best*.

>From a high-level POV, could you please describe the behavior you are trying 
to implement? If you are worried about posting app details in a public 
forum, you can send it to me by PM. Thanks.

>> ? A single fifo_scheduler can service as many asynchronous state machines 
>> as you like.
>
> Yes, you're right. I was thinking about a state machine that isn't bound 
> to one thread. I had the strand concept from the asio library in mind. You 
> can post a work item (event) asynchonous but have a guarantee that 
> execution is serialized.

Ok, can you implement what you want with the current version or do you 
require different behavior?

[snip]
> Ignore the tracer_. This is only a helper object to trace the event 
> ctor/dtor. I think it's a good idea to keep all members of an event const.

In general, I tend to agree. However in this case making the data members 
const doesn't really add much, as events are always passed as const to 
reactions anyway. So, I'm not sure whether such a macro would be used much.

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.