f1446106   
   From: dave@boostpro.com   
      
   on Sun Apr 22 2012, "K. Frank"  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! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)