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

Subject: Re: [Boost-users] [statechart] forward_event()
From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2009-10-12 07:37:57

"Commander Pirx" <CmdPirx_at_[hidden]> wrote in message 
news:hauscr$v5$1_at_ger.gmane.org...
> thanks for the help. I compiled the project with GCC. The behaviour is 
> unchanged. Furthermore I'm not able to reproduce the behaviour in a 
> simplified demo code. I've even tried to debug the statechart library and 
> read the 
> http://www.boost.org/doc/libs/1_40_0/libs/statechart/doc/reference.html#process_event 
> documentation carefully. But I must honestly say, I have not quite 
> understood. Thats why I have a simple question: Is it guaranteed that the 
> innermost states are called first?

It depends :-). Seriously, e.g. in your demo program, there's *no* guarantee 
that the reaction in state X is called first. Whether it is or it isn't 
depends on which innermost states is checked first for a suitable reaction. 
If X is checked first, then you get the behavior of your demo program. If 
either Y or Z is checked first then you get the behavior you observe in your 
application. Exactly which innermost state is checked first is *arbitrary*. 
More importantly, if the first checked innermost state does not define a 
reaction for the event, then its direct *outer* state is checked next (state 
A in your example prog). Hope this clears things up, if not please let me 
know.

> Note: When working with the statechart libraries I got some ideas to 
> improve the "usability". Think about it as a wishlist.
>
> 1. Debugging features, like in the Spirit Library. e.g. easy naming of 
> states, tracing the event route, more debug output (verbose mode)

I'll see what I can do, however in any case this will definitely not make it 
into the next release, as other stuff is already pending.

> 2. Calling the state constructor with an event. something like 
> transit<S>( event );

You already can pass the event to the transit function, but the event is 
never passed to any state constructor (only to the transition action). This 
is a very popular request, but I'm afraid this will not be possible. The 
problem is that the state constructor can be called as a result of a number 
of different events. However, I plan to support a work-around 
(triggering_event, see to-do list) for the next release.

> 3. A process_event() method that acceepts an intrusive pointer. Currently 
> each event will be duplicated (clone()).

No, it should only be cloned if the machine defers the event. Also, if you 
allocate your event with new and assign it to an intrusive_ptr p and then 
pass *p to process_event() then the event should not be cloned.

> 4. A thread safe scheduler. It's hard to use hundreds of instances of the 
> asynchronous_state_machine because each instance needs a thread.  Correct 
> me if I am wrong here.

? A single fifo_scheduler can service as many asynchronous state machines as 
you like.

> 5. Macros to define events, where all memebers are const. I've found that 
> it's error prone to write it by hand again and again.

You mean the macro would save you from having to write const for each 
member?

HTH,

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