unary +

[Steven Pemberton]

In article <1227 at mtx5a.UUCP> esg at mtx5a.UUCP writes:
> The ANSI draft makes case for the unary + operator with
> the following example:
> 
> 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).
> 
> Question: what is the rational for not saying that an
> 	implementation *must* respect parenthesising
> 	as intended rather then providing an extra
> 	operator simply to state "i mean these parenthesis" ?

I find this aspect of the draft disturbing. If you don't care about the
order of evaluation you can write a+b+c. But if you do care, for instance
because of potential overflow or rounding problems, then you should be able
to specify it using parentheses. You shouldn't need to have to use an extra
unary minus: firstly you can easily overlook that sort of thing, secondly
the bug will probably show up only when it's too late. I'm very much against
optimisers that think they know better than you; I'm even more against
standards that condone it.

Steven Pemberton, CWI, Amsterdam; steven at mcvax.uucp