Wed, 20 Jun 90 04:10:42 GMT

Related articles |
---|

Order of Evaluation and Operator Precedence (WAS: Unsafe Optimizations jas@ingres.com (1990-06-20) |

Newsgroups: | comp.compilers |

From: | jas@ingres.com (Jim Shankland) |

Date: | Wed, 20 Jun 90 04:10:42 GMT |

Organization: | The Eddie Group |

Keywords: | code, optimize |

In article <1990Jun14.032437.5554@esegue.segue.boston.ma.us>,

cwitty@csli.Stanford.Edu (Carl Witty) writes:

*> > I would like to note that a number of languages are standardized such that*

*> > order of evaluation of certain items is *not specified*, ...*

*> *

*> I believe that this is not true for C. Instead, the rule is that*

*> the order of evaluation is exactly that specified by the precedence*

*> rules of the language, except in cases where it can be proven not to*

*> make a difference. (For example, on many machines, integer arithmetic*

*> really is commutative and associative.)*

Careful; I think you're on thin ice here, at least in the way you phrased

your statement. Precedence rules of a language don't specify order of

evaluation at all. It is entirely possible for a language to be defined such

that "a + b * c + d" is syntactically equivalent to "a + (b * c) + d" --

i.e., multiplication has higher precedence than addition -- while specifying

nothing about the order in which a, b, c, and d are evaluated. Consider the

case in which a, b, c, and d are function invocations, where each function

outputs "This is function a" (resp. "b", "c", "d"), and returns 1, 2, 3, and

4, respectively. The precedence of multiplication over addition requires

that the final result be 11, not 36; but it says nothing about the order in

which messages appear on the output.

Indeed, C at least used to work exactly this way; the only guarantee was that

the expression would evaluate to 11, and that all four messages would be

printed in some order by the time execution reached the next "sequence point"

-- usually, the end of execution of the statement. Has this changed with

ANSI C?

jas

[ANSI says it must be computed as (a + (b * c)) + d, but the compiler is

free to evaluate the subexpressions in any order it wants, since there's no

sequence point in this expression. -John]

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.