Boost Users :
From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2008-06-18 17:54:52
>> 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.
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.
-- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net