Re: [boost] [statechart] Completion transitions again.
Hi Leandro
Hi
I saw your email[1] via the gmane web interface (did you Cc me?
Not exactly, I forwarded the message:
To: llucarella_at_[hidden] Message-ID: <37229.1564.qm_at_[hidden]>
maybe you mail was eaten by my antispam =).
Probably...
I don't really know how to handle "partial" completion transitions (I mean, with guards). But simple completion transitions could be expressed something like:
struct B; struct A: sc::simple_state< A, Machine > { typedef sc::completion_transition< B > reactions; };
I guess is better to have partial support than no support at all =)
It seems what you want to do with completion transitions can easily be achieved by posting an event in the entry action of a state? That is, the only additional work you'd have to do in comparison to a library supported scenario is to derive from state instead of simple_state and post an event in the ctor? A state that automatically posts an event in its entry action is useful in other scenarios, please see Dynamic choice
It was a problem with my ISP, if it's not much trouble, please Cc/forward me to luca at integratech dyndns org. Thanks! points under:
<http://www.boost.org/libs/statechart/doc/rationale.html#Limitations>
Yes, I know I could do that, but I have to create a dummy event and it looks like a little dirty to me.
I'm considering to add such a class. I'll have to think about the naming and the exact interface though.
Great! What about the other idea? I'm sorry about the lame format, my MUA was messing my ASCII-art =P. Here it is again, I hope this time is more readable: struct ev: sc::event< ev > {}; struct B; struct C; struct A: sc::simple_state< A, Machine > { typedef mpl::list< sc::completion_transition< >, sc::custom_reaction< ev > > reactions; sc::result react(const completion_event&) { if (guard) return transit< B >(); return discard_event(); } sc::result react(const ev&) { if (!guard) return transit< C >(); return discard_event(); } };
Another simple question about statechart: it can handle this?
,-----------------. | S |<--- T | | o--+--> A --> B <--o | | | `-----------------´
Same here. What I wanted to show was: ,-------------------. z | S |<--- T w | x y | o---+--> A ---> B <---o | | | `-------------------´
I want the state machine to start at A, but any other time S is entered, I want to start at B. AFAIK this is possible in UML.
Really? A pointer would be appreciated.
Well, it's not exactly the same but in the presentation[1] linked from boost.statechart web page is an example (page 6). In the example is not the initial pseudostate which goes to the inner state.
Can I express that in boost.statechart?
Not directly, again you could find out which state you want to enter in a initial helper state entry action and then post an appropriate event.
Ok, again this is not very pretty, but I didn't figured this out for this case, I've tried it and it worked, so thanks :)
I think I hit an static assertion when trying to do that (/usr/include/boost/statechart/simple_state.hpp:885: error: invalid application of ‘sizeof’ to incomplete type ‘boost::STATIC_ASSERTION_FAILURE<false>’).
You passed mpl::list filled with multiple initial states? If so, then you tried to create a state with multiple orthogonal regions:
<http://www.boost.org/libs/statechart/doc/tutorial.html#OrthogonalStates>
No, I wasn't using orthogonal regions. I tried to reproduce the error in a smaller example but I couldn't. I attach the example anyways because I hit another error. I'll try to reproduce the previous problem and post it later. TIA -- Leandro Lucarella Integratech S.A. 4571-5252
--- Leandro Lucarella <llucarella@integratech.com.ar> wrote:
It was a problem with my ISP, if it's not much trouble, please Cc/forward me to luca at integratech dyndns org. Thanks!
Ok, I'll try to remember.
I'm considering to add such a class. I'll have to think about the naming and the exact interface though.
Great! What about the other idea? I'm sorry about the lame format, my MUA was messing my ASCII-art =P. Here it is again, I hope this time is more readable:
struct ev: sc::event< ev > {}; struct B; struct C; struct A: sc::simple_state< A, Machine > { typedef mpl::list< sc::completion_transition< >, sc::custom_reaction< ev > > reactions; sc::result react(const completion_event&) { if (guard) return transit< B >(); return discard_event(); } sc::result react(const ev&) { if (!guard) return transit< C >(); return discard_event(); } };
I'm not sure how this is an improvement over the choice-point-like class?
Another simple question about statechart: it can handle this?
,-----------------. | S |<--- T | | o--+--> A --> B <--o | | | `-----------------´
Same here. What I wanted to show was:
,-------------------. z | S |<--- T w | x y | o---+--> A ---> B <---o | | | `-------------------´
Ok, I guess now I see what you want to achieve. Yes, this is a (minor) limitation of the library. The state that you specify as InitialState of an FSM must be an outermost state of the FSM. Similarly, the argument passed for the InnerInitial parameter of simple_state must be a *direct* inner state, please see <http://www.boost.org/libs/statechart/doc/reference.html#ClassTemplatestate_machine> <http://www.boost.org/libs/statechart/doc/reference.html#ClassTemplatesimple_state> Again, this limitation can be overcome easily with the same trick. Specify a dummy outermost state as initial state and then post an event in the entry action that will trigger a transition to the desired state. HTH, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
participants (2)
-
Andreas Huber -
Leandro Lucarella