home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / c / 16229 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  2.5 KB
  1. Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!rpi!crdgw1!rdsunx.crd.ge.com!bart!volpe
  2. From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Order of evaluation
  5. Message-ID: <1992Nov9.181120.4150@crd.ge.com>
  6. Date: 9 Nov 92 18:11:20 GMT
  7. References: <qBak-G@ppcger.ppc.sub.org> <1992Nov9.065342.20862@dartvax.dartmouth.edu>
  8. Sender: volpe@bart (Christopher R Volpe)
  9. Reply-To: volpe@ausable.crd.ge.com
  10. Organization: GE Corporate Research & Development
  11. Lines: 49
  12. Nntp-Posting-Host: bart.crd.ge.com
  13.  
  14. In article <1992Nov9.065342.20862@dartvax.dartmouth.edu>, davidg@polvadera.dartmouth.edu (David Gelhar) writes:
  15. |> In article <qBak-G@ppcger.ppc.sub.org>  writes:
  16. |> > 
  17. |> > So the compiler seems to be allowed to evaluate
  18. |> > 
  19. |> > a * ( b * c )     instead of   a * b * c
  20. |> > 
  21. |> > but not
  22. |> > 
  23. |> > a * ( b / c )     instead of   a * b / c
  24. |> > 
  25. |> > Is this correct?
  26. |> > 
  27. |> 
  28. |> No. The point to remember is that precedence/associativity are NOT the
  29.  
  30. This is all correct...
  31.  
  32. |> same thing as order of evaluation.  The expression "a * b * c" is required
  33. |> to be treated like "(a * b) * c", that is, "a" and "b" are multiplied together
  34. |> and the result is multiplied by "c"; that's the associativity rule.  As it
  35. |> says above, "the precedence and associativity of operands is fully specified".
  36. |> In other words, the parsing of the expression (what operands go with what
  37. |> operators) is precisely defined:  the operands of the rightmost "*" in this
  38. |> example are "a*b" and "c".  What's undefined is the order of evaluation -- 
  39.                                       ^^^^^^^^^ unspecified
  40.  
  41. |> the subexpressions "a", "b" and "c" are not required to be evaluated in any
  42. |> particular order.
  43. |> 
  44. |> The only time order of evaluation matters (indeed, the only time you can
  45. |> even _tell_ what order is being used, without resorting to looking at
  46. |> object code) is when the subexpressions have side effects.  For example,
  47. |> in "a() * b() * c()" there's no telling what order the functions may be
  48. |> called in.  This is fine if the functions have no side effects, but if
  49. |> they do (for example, if they print the function name on the terminal
  50. |> when called) the results are undefined.
  51.  
  52. No, the results are not undefined. The result is that the function names
  53. must be printed out in some order, not necessarily even documented by the
  54. compiler writer. But they must be printed out. The computer is not allowed
  55. to turn into a frog at runtime.
  56.  
  57. -Chris
  58. -- 
  59. ==================
  60. Chris Volpe
  61. G.E. Corporate R&D
  62. volpecr@crd.ge.com
  63.