From: fmatthew5876@googlemail.com   
      
   > This has bitten me more than once:   
   >   
   >   cout << modify_x() << x << endl;   
   >   
   > Unspecified evaluation order of function arguments.  It's something that I'm   
   > normally aware of while calling ordinary functions.  Here, the context and   
   > the operator conspire to mislead one to believe that left-to-right   
   > sequencing will take place, whereas it does not; the compiler transforms   
   > this to nested function calls.   
   >   
   That's another gotcha, I agree. Without intimate knowledge of how function   
   calls work (which is something that a simple interface like operator<<() tries   
   to avoid), you can run into very subtle bugs like this. Even more fun when   
   this code works just fine on one platform/compiler and breaks on another. The   
   interface should be designed so the most obvious expression works as intended   
   without these expert level knowledge corner cases.   
      
   > In IO, order of operations very much matters (something Haskell folks   
   > realized early on) and choosing an output operator which doesn't introduce a   
   > sequence point between each two items output was.. oversight at best.   
   >   
   >   
   > In this sense, overloading comma would have been much better, though, OTOH I   
   > can't remember whether user-defined comma also introduces a sequence point.   
      
   I think overloading the comma operator would be even more confusing. I'm   
   not even sure why overloading this is allowed in the first place.   
      
      
   --   
         [ 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)