order of evaluation parse date s - (nf)

utzoo!decvax!harpo!npoiv!npois!wbux5!wb2!houxz!ihnp4!ixn5c!inuxc!pur-ee!uiucdcs!uicsl!preece utzoo!decvax!harpo!npoiv!npois!wbux5!wb2!houxz!ihnp4!ixn5c!inuxc!pur-ee!uiucdcs!uicsl!preece
Sat Mar 12 16:49:44 AEST 1983


#R:houxj:-22000:uicsl:6400005:000:1091
uicsl!preece    Mar 12 14:31:00 1983

No. Sorry, but I think mine is a reasonable human interpretation
and, in fact, that's the way I'd like the computer to be required
to reach (that is, i'd really like the assignment operator to
force its right side to finish up before assigning). My argument
is as given before:
	a = i++
and
	i = i++
really ought to result in their left-hand sides being the
same. That's an argument from human interpretation, not machine
internals. I suspect it's also compatible with the original
machine purpose of the ++ form, which was to take advantage of
special pdp-11 addressing mode that increments after fetching
the contents of a register; thus they were intended to leave
the incremented value in the variable immediately after obtaining
the old value, not at the end of expression evalutation.

The book is clear - the implementor can do it any way convenient.
And anyone writing the line of code i = i++ deserves to not
know exactly what's going to come out. And anyone writing C code
should be aware that order of evaluation is not controllable.

scott e preece
uiuc coordinated science lab





More information about the Comp.lang.c mailing list