Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.c++.moderated    |    Moderated discussion of C++ superhackery    |    33,346 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 32,843 of 33,346    |
|    Seungbeom Kim to Zeljko Vrba    |
|    Re: iostream replacement    |
|    30 Jan 13 21:28:31    |
   
   From: musiphil@bawi.org   
      
   On 2013-01-26 10:17, Zeljko Vrba wrote:   
   >   
   > 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.   
   >   
   > 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.   
      
   The order of I/O operations does matter, but it doesn't say anything   
   about the evaluation order of arguments. Just as you don't expect that   
      
    printf("%d %d\n", f(), g());   
      
   will evaluate f() before g(), even though you do expect the value of   
   f() will be printed before that of g(), you should have the same   
   expectation for   
      
    cout << f() << ' ' << g() << '\n';   
      
   and I don't agree that f() should evaluated before g() here any more   
   than in the case of printf. (In any non-trivial case, I would write   
   any complex operations on separate statements, and that should take   
   care of the evaluation order as well.)   
      
   You're just misled, and I don't think the blame should necessarily be   
   on the choice of the operator. :)   
      
   > 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.   
      
   No. N3376 footnote 83 says, "an invocation of an overloaded comma   
   operator is an ordinary function call; hence, the evaluations of its   
   argument expressions are unsequenced relative to one another."   
      
   --   
   Seungbeom Kim   
      
      
    [ 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)   
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca