Re: [Boost-users] [statechart]historytransitionsmakestate-local-storage "un-cool"

"Felipe Magno de Almeida" wrote in message news:a2b17b60806211502i447c22e1t9d552dd76b8972a1@mail.gmail.com...

...

http://www.boost.org/doc/libs/1_35_0/libs/statechart/doc/LCA.gif

Ok, if I understand the diagram correctly, this is what happens:

struct Z : sc::simple_state {

};

struct Y : sc::simple_state { };

struct B : sc::simple_state { typedef sc::custom_reaction< Ev > reactions;

boost::statechart::result react( Ev const& e) { // do something return transit<Y>() } };

Yep (Z should of course also be defined somewhere).

...

During the transition triggered by the event Ev, the states X, Y and Z are entered and thus constructed. IIUC, with your approach it is only possible to pass arguments to the constructor of Y, but not to the ones of X and Z, correct? The solution I have in mind (see code in previous post) would allow you to selectively provide whatever arguments you might want to pass to X, Y and/or Z. Admittedly, passing arguments to outer and inner states of the destination might be a less frequent use case but I'd still rather not rule it out.

Thoughts?

IIUC the diagram, the functional factory solution allows both Y and Z to have arguments to its constructors. The Y state could pass the arguments to its base with the arguments for Z constructor, which would then create a factory to instantiate Z.

So you're suggesting that simple_state::simple_state() should be overloaded say 10 times, one templated overload for each distinct number of parameters?

If someone wants to pass arguments to X, then they should transit to X, and X transit to Y IMHO.

Transiting to X could be semantically different from transiting to Y. In the diagram discussed so far it's not but looking at the transitions triggered by e3 and e4 in ... http://i.cmpnet.com/embedded/gifs/9901/9901feat1fig4.gif ... you'll see an example where it is. Transiting to S0 leads to the entry of S0 and S0_1 while transiting to S0_2 leads to the entry of S0 and S0_2.

I see your triggering_event idea, and I find it not very useful because of its necessary downcast and dynamic typing, it also seems to me that the reponsability to receive the arguments continue to be in the just-entered state. Which I find dissatisfying.

I wholeheartedly agree, but apart from your factory suggestion I've not yet seen any good ideas how this could be improved. Even if we were to go the factory route (my version), you'd be forced to implement quite a few factory classes (I guess approximately one for each state ctor with parameters). Sure this is better than anything we have now but it's not particularly elegant.

If I have three or four state constructors, each with different parameters, how would that be implemented with triggering_event? I hope not like this:

if(e1* p = dynamic_cast... else if(e2* p = dynamic_cast...

You could make your events visitable, in which case you could do with a finite number of casts/virtual function calls for any number of state ctors. Of course, this would require the implementation of a visitor class, which isn't exactly elegant either. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.