From: francis.glassborow@btinternet.com   
      
   On 25/09/2012 15:28, James K. Lowden wrote:   
   > On Mon, 24 Sep 2012 12:20:31 CST   
   > fmatthew5876  wrote:   
   >   
   >>> Before answering you specific question, I would comment that I   
   >>> would try to avoid polling.   
   >>>   
   >> In almost any other application I would agree. However in a game   
   >> that runs its main loop 60 times per second, I think polling to see   
   >> if the IO is done each frame makes sense.   
   >   
   > Why?  Machines are fast and people are slow.  Even *video* is slow   
   > if you're talking about refresh rates.   
   >   
   > A pretty slow processor these days executes a billion or so cycles   
   > per second, and instructions take under 100 cycles.  A 100-cycle   
   > instruction called 100 times a second would use less than 0.001% of   
   > the processor's capacity.   
      
   I am unclear about what point you are making. Polling was generally a   
   'bad' solution on slow hardware but on modern hardware running at the   
   speeds you mention it does not seem such a bad thing when it often   
   simplifies the programming and allows the programmer to focus on the   
   work he wants to get done.   
      
   The question about any solution is 'does it work sufficiently fast?'   
      
   Many years ago I wanted to do name completion on a z80 based machine   
   so that as the user typed in a name the candidate list would be   
   progressively reduced until there were fewer than 9 at which stage the   
   user would be offered a list to select from. I really had to work at   
   trimming cycles to beat fast typists by being able to process the data   
   between keystrokes (the real fun was ensuring that backspace was   
   correctly handled). These days such a task would be trivial as the   
   processors are orders of magnitude faster.   
      
   I can remember a book (can't recall the title) where the author   
   strongly advocated writing clean easily maintained solutions and only   
   optimising in release versions. The basis being that a micro   
   optimisation might be essential today to delver an application that   
   works fast enough but by the next release it may no longer be so keep   
   the code base simple and use that as the basis for each release,   
   optimising where needed.   
      
   Francis   
      
      
   --   
         [ 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)