Boost logo

Boost Users :

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. 

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