From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2008-06-19 16:22:51
"Felipe Magno de Almeida" <felipe.m.almeida_at_[hidden]> wrote in message
news:a2b17b60806182303u493e7061i8d36d68c59d27f1e_at_mail.gmail.com...
>>> 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.