Re: [Boost-users] [statechart] Working with state history -compilation errors

From: Andreas Huber (ahd6974-spamgroupstrap_at_[hidden])
Date: 2005-10-17 16:49:16

Mick Hollins wrote:
>> Note that this is very much in line with the UML notation. A
>> transition to history always goes to a H disc first and from that H
>> disc you have another arrow to the default state.
>
> Initially I thought it was not quite in line with UML since the
> boost::statechart implementation allows a different default arrow to
> be specified for each transition to a H disc, whereas UML only allows
> a single arrow out of a H disc.
>
> But I just realised that afaict UML does not disallow having more
> than one H disc in a parent state. As such you can have 2 H discs
> each with a different default state, and boost::statechart supports
> that.

I faintly remember seeing a statechart diagram with more than one
history disc in one state. This was enough for me to choose a design
that allows for that. I can't say offhand whether or not UML explicitly
allows it.

>> I checked the docs and I can't find any examples that display the
>> wrong syntax you used. A pointer would be appreciated.
>
> I don't believe your docs are wrong. It is just that it is easy to
> misread them as it seems natural to expect that you would say:
>
>     sc::shallow_history<StateA>
>
> since you are requesting a transition to one of the sub-states of
> StateA. Saying:
>
>     sc::shallow_history<StateA1>
>
> just reads a little funny since you may or may not be transitioning
> to StateA1. The following, while redundant, might actually be easier
> for people to read:
>
>      sc::shallow_history<StateA, StateA1>
>
> where the first parameter specifies the parent state to which you are
> performing a history transition, and the second parameter specifies
> the default state.

I'm not sure. In the UML diagram the arrow doesn't point to StateA
either so you have a very similar problem there. Plus, I don't like the
unnecessary redundancy.

Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.