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

  1. Path: sparky!uunet!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!dog.ee.lbl.gov!horse.ee.lbl.gov!torek
  2. From: torek@horse.ee.lbl.gov (Chris Torek)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Order of evaluation?
  5. Date: 8 Nov 1992 09:30:15 GMT
  6. Organization: Lawrence Berkeley Laboratory, Berkeley
  7. Lines: 66
  8. Message-ID: <27294@dog.ee.lbl.gov>
  9. References: <3736@dozo.and.nl> <1992Oct27.002204.11825@den.mmc.com> <josef.720691377@uranium> <1992Nov2.192805.17329@CSD-NewsHost.Stanford.EDU> <1dau8nINNk59@uranium.sto.pdb.sni.de> <1992Nov6.163023.1649@mksol.dseg.ti.com>
  10. Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
  11. NNTP-Posting-Host: 128.3.112.15
  12.  
  13. In <1dau8nINNk59@uranium.sto.pdb.sni.de> Josef Moellers
  14. <mollers.pad@sni.de> writes:
  15. >>E.g. in an expression like
  16. >>    a() * b() * c() * e() * f() * g()
  17. >>the compiler might decide to generate code to test the intermediate
  18. >>result to be 0, in which case the rest of the expression might be
  19. >>dropped.
  20.  
  21. In article <1992Nov6.163023.1649@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com
  22. (fred j mccall 575-3539) writes:
  23. >I don't think this applies.  I believe the whole 'expression' must be
  24. >evaluated and the compiler is not allowed to short-circuit that.
  25.  
  26. Fred McCall is correct, modulo caveats about `observable behavior'.
  27.  
  28. `Order of evaluation', `precedence', and `sequence points' are all
  29. different issues in C.
  30.  
  31. Sequence points are an ANSI C invention---and a good one---that allow
  32. you to define a partial order on expression evaluation.  If two
  33. expressions e1 and e2 are separated by one or more sequence points, you
  34. (the programmer) are assured that all side effects in e1 have
  35. apparently happened before e2 is apparently started.  Thus, given:
  36.  
  37.     i++; i += i;    /* sequence points at semicolons */
  38.  
  39. we can tell what we will get if we print (or otherwise examine) the
  40. value in i, although we do not actually know whether we are seeing the
  41. value *really* in i, or just something that *looks exactly the same*
  42. (and is there any difference? if a tree falls in the woods and there
  43. is no one to hear it, is that noise pollution?).
  44.  
  45. Precedence is a syntax issue; ANSI C uses a grammar that avoids it
  46. entirely, but there are equivalent precedence grammars that are easier
  47. to remember, so people tend to use the latter.  Unfortunately
  48.  
  49. Order of evaluation is generally not defined in C.  This is modified by
  50. sequence points:  Because we know side effects have occurred---and
  51. remember that output is a side effect---any time we attempt to observe
  52. the order of an evaluation containing sequence points, that observation
  53. will show the order guaranteed by those sequence points.
  54.  
  55. >... it would have to be evaluted completely (all functions called)
  56. >even if the first multiplication produced a zero.  In other words,
  57. >side effects of the functions must happen.
  58.  
  59. Right.  Note, however, that the order in which those functions are
  60. called is undefined---and if it turns out that any function does
  61. nothing, the compiler is free to omit the call, since we will not be
  62. able to tell that it did so.  Similarly, the compiler could omit the
  63. rest of the multiplies if the first produces 0, because again we will
  64. not be able to tell.
  65.  
  66. The only way to find out whether the compiler is using smoke and
  67. mirrors to *simulate* doing everything is to go outside the C
  68. language.  For instance, you could disassemble the object code to see
  69. whether
  70.  
  71.     i++; i += i;
  72.  
  73. was compiled as `add 1 to i, then add i to i' or as `i = (i + 1) << 1'.
  74. A printf() in between will not suffice, because the compiler can simply
  75. generate different code that time.
  76. -- 
  77. In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
  78. Berkeley, CA        Domain:    torek@ee.lbl.gov
  79.