home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / c / 16190 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  2.6 KB
  1. Path: sparky!uunet!mcsun!Germany.EU.net!ira.uka.de!smurf.sub.org!ppcnet!ppcger!Sepp
  2. Message-ID: <qBak-G@ppcger.ppc.sub.org>
  3. From: Sepp@ppcger.ppc.sub.org (Josef Wolf)
  4. Newsgroups: comp.lang.c
  5. Subject: Re: Order of evaluation?
  6. Distribution: world
  7. Organization: PPC Germersheim, Germany
  8. Date: 8 Nov 92 16:39:01 GMT
  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.125409.23455@unipalm.co.uk>
  10. Lines: 57
  11.  
  12. In <1992Nov6.125409.23455@unipalm.co.uk> tim@unipalm.co.uk (Tim Goodwin) writes:
  13. ] Josef Moellers <mollers.pad@sni.de> writes:
  14. [ ... ]
  15. ] >    a() * b() * c() * e() * f() * g()
  16. [ ... ]
  17. ] In the quoted example, each of the functions must be evaluated (although
  18. ] there is no guarantee about the order in which they are evaluated).  It
  19. ] is possible that the compiler might avoid some of the multiplications,
  20. ] if it happens to notice that they are unnecessary, but it may not omit
  21. ] any of the function calls.
  22.  
  23. Well, let's please go back to the original thread. Say: is the compiler
  24. allowed to evaluate the expression given above in the following order:
  25.  
  26. a() * (b() * c()) * e() * f() * g() ?
  27.  
  28. Let's take a look at Section A7.6:
  29.  
  30.    A7.6 Multiplicative operators
  31.  
  32.      The multiplicative operators *, /, and % group left to right.
  33.    [ ... ]
  34.  
  35. So the world seems to be OK. But look at Section A7:
  36.  
  37.    A7 Expressions
  38.  
  39.    [ ... ]
  40.      The precedence and associativity of operands is fully specified, but
  41.    the order of evaluation of expressions is, with certain exceptions,
  42.        ^^^^^^^^^^^^^^^^^^^
  43.    undefined, even if the subexpressions involve side effects. That is,
  44.    unless the definition of an operator guarantees that its operands are
  45.    evaluated in a particular order, the implementation is free to evaluate
  46.    operands in any order, or even to interleave their evaluation. [ ... ]
  47.         This rule revokes the previous freedom to reorder expressions with
  48.         operators that are mathematically commutative and associative, but
  49.         can fail to be computationally associative. [ ... ]
  50.  
  51. So the compiler seems to be allowed to evaluate
  52.  
  53. a * ( b * c )     instead of   a * b * c
  54.  
  55. but not
  56.  
  57. a * ( b / c )     instead of   a * b / c
  58.  
  59. Is this correct?
  60.  
  61. Greetings
  62.     Sepp
  63.  
  64. -- 
  65. |   Josef Wolf,  Germersheim,  Germany    aka    sepp@ppcger.ppc.sub.org   |
  66. |    also available via    ..!uunet.uu.net!ira.uka.de!smurf!ppcger!sepp    |
  67. |--------------------------------------------------------------------------|
  68. | ...und wieviel brave Deutsche haben wieder nichts geschnallt... (Marius) |
  69.