Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!mcvax!boring!steven
From: steven@boring.uucp (Steven Pemberton)
Newsgroups: net.lang.c
Subject: Re: unary +
Message-ID: <6831@boring.UUCP>
Date: Fri, 14-Mar-86 10:58:11 EST
Article-I.D.: boring.6831
Posted: Fri Mar 14 10:58:11 1986
Date-Received: Sun, 16-Mar-86 09:42:16 EST
References: <1227@mtx5a.UUCP>
Reply-To: steven@mcvax.UUCP (Steven Pemberton)
Distribution: net
Organization: CWI, Amsterdam
Lines: 24
Apparently-To: rnews@mcvax

In article <1227@mtx5a.UUCP> esg@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@mcvax.uucp