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

From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2008-06-18 17:54:52

Hi Felipe

>> 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?

No, unfortunately.

> I find two-phase construction not something desirable.

Neither do I, but I have come to the conclusion that it's probably the best 
of all approaches. As mentioned, triggering_event() wrecks type-safety and 
type-safely calling the right constructor is only a half-backed solution 
(doesn't work with exit()).

triggering_event() might still be necessary for rare corner-cases, which is 
why it is still on the to-do list. I certainly haven't received many 
requests in this direction.

> I would really want to pass a state instance to transit<>().
> Why isn't this available?

Um, why do you want pass a *state* object to transit<>()? State construction 
& destruction must be done by the state machine itself.

Regards,

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