home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / c / 16198 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  2.7 KB

  1. Path: sparky!uunet!usc!rpi!bu.edu!dartvax!news
  2. From: davidg@polvadera.dartmouth.edu (David Gelhar)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Order of evaluation
  5. Message-ID: <1992Nov9.065342.20862@dartvax.dartmouth.edu>
  6. Date: 9 Nov 92 06:53:42 GMT
  7. References: <qBak-G@ppcger.ppc.sub.org>
  8. Sender: news@dartvax.dartmouth.edu (The News Manager)
  9. Organization: Dartmouth College, Hanover, NH
  10. Lines: 55
  11.  
  12. In article <qBak-G@ppcger.ppc.sub.org>  writes:
  13.  
  14. > Let's take a look at Section A7.6:
  15. >    A7.6 Multiplicative operators
  16. >      The multiplicative operators *, /, and % group left to right.
  17. >    [ ... ]
  18. > So the world seems to be OK. But look at Section A7:
  19. >    A7 Expressions
  20. >    [ ... ]
  21. >      The precedence and associativity of operands is fully specified, but
  22. >    the order of evaluation of expressions is, with certain exceptions,
  23. >        ^^^^^^^^^^^^^^^^^^^
  24. >    undefined, even if the subexpressions involve side effects. That is,
  25. >    unless the definition of an operator guarantees that its operands are
  26. >    evaluated in a particular order, the implementation is free to evaluate
  27. >    operands in any order, or even to interleave their evaluation. [ ... ]
  28. >         This rule revokes the previous freedom to reorder expressions with
  29. >         operators that are mathematically commutative and associative, but
  30. >         can fail to be computationally associative. [ ... ]
  31. > So the compiler seems to be allowed to evaluate
  32. > a * ( b * c )     instead of   a * b * c
  33. > but not
  34. > a * ( b / c )     instead of   a * b / c
  35. > Is this correct?
  36.  
  37. No. The point to remember is that precedence/associativity are NOT the
  38. same thing as order of evaluation.  The expression "a * b * c" is required
  39. to be treated like "(a * b) * c", that is, "a" and "b" are multiplied together
  40. and the result is multiplied by "c"; that's the associativity rule.  As it
  41. says above, "the precedence and associativity of operands is fully specified".
  42. In other words, the parsing of the expression (what operands go with what
  43. operators) is precisely defined:  the operands of the rightmost "*" in this
  44. example are "a*b" and "c".  What's undefined is the order of evaluation -- 
  45. the subexpressions "a", "b" and "c" are not required to be evaluated in any
  46. particular order.
  47.  
  48. The only time order of evaluation matters (indeed, the only time you can
  49. even _tell_ what order is being used, without resorting to looking at
  50. object code) is when the subexpressions have side effects.  For example,
  51. in "a() * b() * c()" there's no telling what order the functions may be
  52. called in.  This is fine if the functions have no side effects, but if
  53. they do (for example, if they print the function name on the terminal
  54. when called) the results are undefined.
  55.