Actually, I have myself an use case for passing arguments to outer states.
I'm just throwing here a suggestion: How about having another way of transiting in this case?
cascate_transit<state1>(inner_arg1, inner_arg2) .outer<state2>(middle_arg1, middle_arg2) .outer<state3>(outer_arg1, middle_arg2);
Something in this direction could work. With .outer you mean to imply that state2 is a direct outer state of state1, right? What if state2 doesn't require any ctor parameters but state3 does? Also, here's a somewhat esoteric but IMO still not unreasonable case: http://www.boost.org/doc/libs/1_35_0/libs/statechart/doc/CameraWithHistory2.... In the transition triggered by EvShutterReleased, it is clear that we're entering NotShooting but it's not clear whether we will enter Idle or Configuring (this depends on which of the two was active when we last left NotShooting). IMO, you should be able to supply ctor parameters for none, one or even both of the inner states of NotShooting. At this point I think it is kind of obvious that there's no point in enforcing an order of supplying ctor arguments. We need a map that associates a type with a construction function, with no particular order of map entries. Exactly how said map should look like and how it is constructed is not yet clear to me. I hope I'll find the time to toy around a little bit.
And completely off-topic: Also, a state that is instantiated through tss (when multithreaded), or through a global variable (when single-threaded) could be good.
I don't think I understand. Could you elaborate a little bit on this one? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.