wapd (02/25/83)
Recently I came across a C compiler for a certain microprocessor (never mind which one) that evaluates strange expressions in an order that I think may be illegal. If the program starts with : int i ; int table[5] ; i=0 ; What happens if the next line is one of the following ? table[i++]=i++ ; table[++i]=++i ; table[i++]=++i ; and so on ... Well, what happens is that all pre-increments are done first, then all expressions are evaluated using the values of variables at that point, the assignment is performed, and then all post-increments are performed. Does this violate the C standard ? Doesn't C guarantee that each expression will be evaluated entirely before another expression is evaluated ? I know that C doesn't guarantee the order in which expressions are evaluated, but isn't each expression indivisibly evaluated ? Something different happens depending on whether the declaration is "int i ;" or "register int i ;", but I don't want to think about that one. Bill Dietrich houxj!wapd PS: I wouldn't be caught dead writing code like that.
steve (02/26/83)
If you check p. 50 of K&R you will find that in the statement a[i] = i++; it is undefined whether the value of "i" used to index into "a" is its value before or after it is incremented. I think this answers your question: in all cases it is compiler-dependent and not defined by the language. Steve Kochan whuxa!steve
dmmartindale (02/26/83)
The problem here is due to a misunderstanding. In some languages, the statement "a[i++] = i++;" would be called an "assignment statement", with the subscript considered one expression, the stuff on the right hand of the assignment operator another expression, and the assignment operator itself not part of any expression. In C, however, the assignment operator is just like any other expression operator, and the whole thing above is a single expression. (Note that most statements in C are simply an expression followed by a semicolon.) So the compiler is justified in doing all the pre-increments before and all the post-increments after the assignment itself.
doug@terak.UUCP (Doug Pardee) (08/30/85)
> >OK, I understand that order of evaluation is not guaranteed. I assume that > >was done to make compilers easier to write. Is there any other reason? Does > >it really make compilers easier to write? > > Also, allowing the compiler to reorder the expression within certain > limits allows it to do some optimizations. Most code is not affected by > order of evaluation, and C does allow an order to be forced (by assigning > an explicit temporary), so I think this is very reasonable. What drives me up a wall is that C does *not* allow an order to be forced by using parentheses! The compiler is at liberty to ignore parens which group operators of the same precedence. <e.g. a+(b+c)> I don't think much of the notion of having to store intermediate results just to get the correct answer. -- Doug Pardee -- CalComp -- {seismo!noao,decvax!noao,ihnp4}!terak!doug
BJORNDAS%CLARGRAD.BITNET@WISCVM.WISC.EDU (09/29/86)
The expression a = ((b=1,b) + (b=2,b) + (b=3,b)) evaluates correctly to 6 on the ALCOR C compiler running on a TRS-80 Model 4, TRSDOS 6.2. (This is also the broken compiler which prompted my earlier question about chars being promoted to ints in function calls, lest I feel too proud :-).) Sterling Bjorndahl, Claremont Graduate School BJORNDAS @ CLARGRAD on BITNET