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.