Boost logo

Boost Users :

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.


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, kalb at, bjorn.karlsson at, gregod at, wekempf at