on Sun Apr 22 2012, "K. Frank" <kfrank29.c-AT-gmail.com> wrote:

>> A few additional points:
>>
>> * there are real scenarios where you don't know the event until
>> runtime, e.g. if events are queued somewhere.
>
> I don't follow what you're saying here. Isn't the normal -- and
> by far and away most common -- use case the one where you don't
> know the events until runtime? Which gui button was clicked,
> what signal came from some hardware controller, and so on?

I don't know what's most common. But, for example, it's very common
that you can attach different actions to different GUI buttons. So if
you can have one GUI button doing fsm.process_event(play()) and another
doing fsm.process_event(stop()), then discriminating the event has already
been taken care of for you "at runtime," by the GUI framework. There's
no need to pay the cost again in the FSM.

So I guess the answer is that it's probably most common that at some
level (in the hardware, if nowehere else) you don't know the events
until runtime, but it's also very common that something has already
given you a separate hook for each incoming event.

HTH,

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]