Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-adm!brl-smoke!smoke!rbj@icst-cmr From: rbj@icst-cmr (Root Boy Jim) Newsgroups: net.lang.c Subject: Re: unary + Message-ID: <2447@brl-smoke.ARPA> Date: Mon, 7-Apr-86 15:53:31 EST Article-I.D.: brl-smok.2447 Posted: Mon Apr 7 15:53:31 1986 Date-Received: Thu, 10-Apr-86 00:42:25 EST Sender: news@brl-smoke.ARPA Lines: 70 ~ (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