Re: [Boost-users] [statechart] history transitionsmakestate-local-storage "un-cool"

From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2008-06-17 23:22:41

On Mon, Oct 17, 2005 at 6:48 PM, Andreas Huber
<ahd6974-spamgroupstrap_at_[hidden]> wrote:
>

[snip]

>> Om the subject of two phase construction, I often find that you need
>> it for states anyway, as what you often want is the ability to
>> provide parameters to the constructor of a state to which you are
>> transitioning.
>
> Yes, that is a common problem. AFAICT, UML only allows for event access
> in a transition action but not in entry and exit actions.
>
>> The approach I've settled on for this is to post an
>> "initialisation event" just before transitioning state, so that the
>> initialisation event will be the first event handled by the state to
>> which I am transitioning. Is there a better way to achieve this?
>
> Not currently. triggering_event(), which is on position 2 of the to-do
> list, would allow ctors, dtors & exit() functions to access the event
> that triggered the state entry or exit. Since these can be triggered by
> events of different types, the function only returns the base class
> event, which needs to be down-cast by the user. I'm not very happy with
> this interface though, so I will also consider the possibility to
> type-safely pass the triggering event to state constructors that accept
> a corresponding parameter. AFAICS, this would require a SFINAE compiler
> (i.e. a very compliant compiler). Unfortunately, due to inevitable
> type-erasure when the state is stored in state_machine, the same doesn't
> seem to be possible with exit() functions, at least not without major
> performance hits.

Hi, has anything improved in this matter?
I find two-phase construction not something desirable.
I would really want to pass a state instance to transit<>().
Why isn't this available?

[snip]

-- 
Felipe Magno de Almeida