unary +

jdz at wucec2.UUCP jdz at wucec2.UUCP
Sun Mar 23 06:39:59 AEST 1986


In article <138 at myab.UUCP> lars at myab.UUCP (lars) writes:
>In article <1227 at mtx5a.UUCP> esg at mtx5a.UUCP writes:
>>An expression a + (b + c) may be calculated by some
>>implementations as (a + b) + c. To enforce the
>>intended precedence of operations one should use
>>a + +(b + c).

>Why not use this this construction:

>a + (volatile)(b + c) ?

>Would this imply that the access of 'b' and 'c' is "volatile" ?

Yes, it would; so a compiler which knew the value of B was stil hanging around
in some register would be required to go back to main memory and load it
in again. Same for A. That is the meaning of volatile; remembered/saved copies
of the variable are not to be used.

>In that case the following should also work:

>(volatile)(a + (b + c)).

Same problem. volatile is not the answer; it already does something else.

This is the same problem I have withthe suggestion that parentheses should
indicate desired order of evaluation. As has already been pointed out, the
poor parenthesis already does duty to change precedence of operations. Using
square brackets would just serve to confuse people (oh, how neat! says the
beginning C programmer - I can use parens and brackets in my expressions
interchangeably! Well...)

Unary plus makes sense to me - it hangs around in the parse tree, which is
one of the things optimizers optimize. They don't see the source text; they
either look at the parse tree, intermediate text (probably without parens and
in prefix or postfix form), or the assembler output. No parens to look at.

As has been mentioned already, the unary + operator acts a a signal to any
optimizer to not migrate things from below the node to above it and
visa-versa.

[oh, yes - if there are optimizers that operate on the input source, don't
flame me for the above assumption. I'd love to hear more about them,though.]
-- 
Jason D. Zions			...!{seismo,cbosgd,ihnp4}!wucs!wucec2!jdz
Box 1045 Washington University
St. Louis MO 63130  USA		(314) 889-6160
Nope, I didn't say nothing. Just random noise.



More information about the Comp.lang.c mailing list