unary +

Root Boy Jim rbj at icst-cmr
Tue Apr 8 06:53:31 AEST 1986


~ (OOE = Order-Of-Evaluation.)
~ 
~ [0]  "+()" is a bad notation, no doubt about it.  If unary plus is to have
~ any meaning at all, it should be the obvious arithmetical no-op on real
~ numerical arguments.

Which is probably why they even *considered* adding it. It is non-intuitive
for unary plus to be disallowed.
 
~ [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.
Anyone for a reverse polish notation C spec?

~ [2]  The way to specifically disambiguate in the current standard is to use
~ an explicit temporary: "temp=b+c; a+temp".  I presume the reason for the
~ proposed unary plus operator is to remove the need for a declaration, and
~ to reduce the compiler's work.  (It's not easy for the compiler to know
~ that "temp=b+c; a+temp" can be reduced to "a+ +(b+c)", especially if the
~ same variable "temp" is used elsewhere for the same trick.)
 
The spirit of C is (was) minimalism. If you don't need it, don't put
it in the language. Unary plus probably only made it in because someone
discovered that it could do double duty; that of eliminating those
irritating temporarys.

~ [3]  Someone proposed using "a+(volatile)(b+c)".  I think this is workable,
~ though not quite the same meaning as volatile applied to a simple variable.
 
Workable maybe, but ugly by my standards. Volatile should be a keyword
no one has to use except when writing device drivers.

~ [4]  Finally, the most important point.  WHO THE HELL IS GOING TO USE SUCH
~ A FEATURE ANYWAY?  I have *never*, to my recollection, tried to force OOE,
~ nor seen any program that did (excluding the use of temporaries to control
~ the order of side effects, which is not addressed by the unary plus issue).
~ Given its extreme rarity, I think the "subtle bugs" and "confusion among
~ [unfamiliar] users" are irrelevant -- except that someone may make a typo
~ and accidentally invoke a unary plus.
 
If you are going to live up to your nickname, you had better do some
research before posting. We all know about `MAXINT', right? Well
postulate `MAXFLT' & `MINFLT', which are BMF & SLF floating point numbers.
We all know that `(MAXFLT + MINFLT - MAXFLT)' is `MINFLT' right? Wrong!
It's zero on most machines because the sum of the first two terms generates
too many bits of significance. MINFLT is just a drop in the bucket.

~ The alleged reason for "=" being assignment rather than compare is that
~ assignment is used more often and deserves the shorter symbol.  (I might
~ believe this argument if they'd also applied it to "&&".)  In my opinion,
~ the OOE operation does not deserve a one-character symbol, nor a new
~ keyword.
 
It is debatable whether `&' or `&&' is used more commonly. The Bitwise
And (&) is certainly a more familiar construct and probably deserves
the single symbol token. Also, the Logical And appears mostly in
conditionals where the `==' mostly does. It just `looks conditional'.

~ I vote for [3], given the prior existence of an appropriate keyword.
 
You are entitled to your opinion.

~ Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
 
	(Root Boy) Jim Cottrell		<rbj at cmr>



More information about the Comp.lang.c mailing list