unary +

[Gregory Smith]

In article <2447 at brl-smoke.ARPA> rbj at icst-cmr (Root Boy Jim) writes:
>~ (OOE = Order-Of-Evaluation.)
>~ [1]  "()" is worse.  The code generator should NOT have to assume all
>~ parens specify OOE.  In the example given it looks intuitive (since I could
>~ write "a+b+c" for dont-care, obviously "(a+b)+c" or "a+(b+c)" reflect
>~ intended OOE), but it's not true in general.  Also, it's already been
>~ observed that expanded macros often have extraneous parens.
>
>Which serve to specify OOE. I think it slightly weird that K&R allowed
>rearranging OOE for associative operators, but mostly it doesn't hurt.

Parentheses DO NOT SPECIFY ORDER OF EVALUATION ( at least not in this
sense). They are used to override the bindings of operators. In compiler
terms, this means that ()'s are used to control the shape of the parse
tree, but they do not otherwise affect the order of the code generated for it.
Consider that ?: groups right-to-left [ meaning a?b:c?d:e == a?b:(c?d:e)]
but is evaluated left to right: 'a' is always done first. Don't look at
K&R page 215 - it is wrong on this point. Pg. 49 is correct.

>Anyone for a reverse polish notation C spec?

*No*. Try Forth. You'll soon agree.
-- 
"If you aren't making any mistakes, you aren't doing anything".
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg