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

From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2008-06-24 16:00:34

> 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.gif>

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.