home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / cplus / 13521 < prev    next >
Encoding:
Text File  |  1992-09-10  |  1.6 KB  |  45 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!spool.mu.edu!agate!ames!pacbell.com!well!johnrp
  3. From: johnrp@well.sf.ca.us (John Panzer)
  4. Subject: Re: Answers on a postcard...
  5. Message-ID: <BuEHGr.Kx@well.sf.ca.us>
  6. Sender: news@well.sf.ca.us
  7. Organization: Whole Earth 'Lectronic Link
  8. References: <92254.104002KKEYTE@ESOC.BITNET> <1992Sep10.174914.838@taumet.com>
  9. Date: Fri, 11 Sep 1992 06:17:15 GMT
  10. Lines: 33
  11.  
  12. In article <1992Sep10.174914.838@taumet.com> steve@taumet.com (Steve Clamage) writes:
  13. >Karl Keyte <KKEYTE@ESOC.BITNET> writes:
  14.  
  15. (Class X which defines operator,() )
  16.  
  17. >|   X x;
  18. >|   cout << "Value is " << (x=1, x+1) << endl;
  19.  
  20. (General surprise that order of evaluation of x=1, x+1 is undefined)
  21.  
  22. >
  23. >In the expression in parens, it is unspecified whether "x=1" or
  24. >"x+1" is evaluated first.  They are arguments to the "operator,()"
  25. >function, not the left and right side of a comma-expression.  If
  26. >"x+1" is evaluated first, which is legal, it will use an
  27. >uninitialized "x.value".
  28. >
  29. >Don't write code which depends on unspecified order of evaluation.
  30. >
  31. >If there were no "op,()", the "," would mark a comma-expression,
  32. >and the "x=1" would have to be evaluated first; in that case the
  33. >whole expression would be well-defined.
  34.  
  35. Wow.  So this means (for example) that if you define && for a class, 
  36. chained && expressions no longer have a defined order of evaluation.
  37. I subconsciously expected the object to be evaluated first in calls
  38. like Expr1.operator&&(Expr2).  I might even propose this as a new
  39. constraint, except that there are too many darn proposals already. :^)
  40.  
  41. John Panzer
  42. johnrp@well.sf.ca.us
  43.  
  44.  
  45.