From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2007-08-29 18:11:06
> I saw your email via the gmane web interface (did you Cc me?
Not exactly, I forwarded the message:
> you mail was eaten by my antispam =).
> 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 points under:
I'm considering to add such a class. I'll have to think about the naming and
the exact interface though.
> Another simple question about statechart: it can handle this?
> | S |<--- T
> | |
> 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.
> 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.
> 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
You passed mpl::list filled with multiple initial states? If so, then you
tried to create a state with multiple orthogonal regions:
-- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk