"Felipe Magno de Almeida"
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.
I understand it conceptually, but practically I can't see much difference from I constructing it or the machine doing it.
A state constructor is the entry action of a state and the destructor is the exit action of a state (there's also exit() but let's ignore that for the moment). Now, during a transition these actions must be called in a well-defined order (as mandated by UML, Harel, etc.). If you construct the destination state before the origin state is destructed then said order is violated.
All I wanted is to pass constructor arguments. Explicitly or not.
I do agree that this is sometimes desirable. So far, I have worked around this by posting an event carrying the data (often, the posted event is a copy of the event triggering the transition). The destination state simply defines an in_state_reaction to pick up the previously posted event. Sure, this is kind of ugly.
The machine would have to copy the state, but I don't mind if at least I can give arguments to the next state somehow. Can't we pass the arguments to transit<>() ?
I guess we could, but as mentioned this requires some pretty involved compiler magic.
I'm not an expert in statechart implementation, but it shouldn't be that hard, transit<> could pass a boost::factory to the statechart internals responsible for instantiating a state.
Hm, something along these lines might actually work. Remember though, that a transition could potentially create more than one state object, so an example factory object could look like this: class MyStateFactory { public: MyStateFactory(/* arguments that should be passed to state ctors */) { /* store arguments in data members */ } template<class State> boost::intrusive_ptr<State> construct() { return new State(/* ctor arguments here */); } }; construct() would be called once for each state that is created as a result of a transition. If you want to treat different state types differently you'd need to specialize. Thoughts? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.