K
karthikbalaguru
Hi,
What is the use of the Unary + Operator ?
Thx in advans,
Karthik Balaguru
What is the use of the Unary + Operator ?
Thx in advans,
Karthik Balaguru
K
karthikbalaguru
Cool !!
I was eager to know of its use becuase some
referred it as dummy operator.
So, it is applicable only in this scenario and not
in other places.
Karthik Balaguru
S
Stephen Sprunk
karthikbalaguru said:
It can be applied in lots of places, but it's almost always pointless to
do so. This is one specific exception, and not a particularly useful
one either since, if you can remember to put the + in as a defense
against mistyping ==, you can just as easily remember to get the ==
right. A better example would be in a list of constants where you
wanted to make the sign of every constant, both positive and negative,
explicit rather than only putting a sign on the negative ones, which
might make it easier to read or help detect typos.
However, I suspect that it was included mainly for completeness and
because there was nothing else one could reasonably do with a unary +
that wouldn't confuse a lot of programmers.
S
P
Peter Nilsson
Which people like this?
Note that its application to an integer of rank less
than int will cause promotion of that int. [I have used
this fact in C++, but not in C.]
For example, suppose c is a char, sizeof c need not
equal sizeof +c.
Note that its application to an integer of rank less
than int will cause promotion of that int. [I have used
this fact in C++, but not in C.]
For example, suppose c is a char, sizeof c need not
equal sizeof +c.
E
Eric Sosman
Peter said:
slly ppl, as i sed b4.
(Ambiguity intentional.)
O
osmium
blargg said:
That's the best response we are likely to see.
D
Dik T. Winter
The unary + was added in the process for a fairly bizarre reason. Originally
in C all expressions could be rearranged when the *mathematical* result would
remain the same, it did not matter whether the *numerical* result would remain
the same. This gave numerical mathematicians problems. Of course they could
use additional variables and subexpressions, but in many cases the result
would not be nice to look at. So it was invented that if an expression
between parenthesis was preceded by a unary +, the subexpression had to
be calculated as is, and parts could not be moved out from it. So:
a + +(b - a)
must first calculate b-a and afterwards add the result to a. On the
other hand:
a + (b - a)
could be rearranged, the compiler would see that the a's cancel and could
give only b as result of the expression.
That was the start of the career of unary + in C.
Of course it is no longer necessary for that purpose as the current wording
is that an expression can be rearranged if the *numerical* result remains
the same, and so in floating-point, a + (b - a) can not be rearranged at all.
K
Keith Thompson
Dik T. Winter said:
That's an interesting explanation, and one that I hadn't heard before.
Here's what the the rationale for the 1989 ANSI C standard says
<http://www.lysator.liu.se/c/rat/c3.html#3-3-3-3>:
Unary plus was adopted by the Committee from several
implementations, for symmetry with unary minus.
It may be that those "several implementations" added unary + for the
reasons you've presented.
C
CBFalconer
Dik T. Winter said:
Huh? Why can't it be rearranged, since cancelling a's produces the
same result, barring overflow conditions?
D
Dik T. Winter
Ineed, it is already more than twenty years ago, but I still remember when
I heard that it was first introduced. The most awful hack in a computer
language I had ever seen. Some part of the aftermath can still be found
in this thread in comp.std.c in 1991:
<http://groups.google.nl/group/comp.std.c/browse_frm/thread/bc4a820e2a1decbe>
Apparently the hack was mentioned in Harbison & Steele of 1987. See also
<http://groups.google.nl/group/net.lang.c/browse_frm/thread/34215286edacbc38>
from around 1986 from net.lang.c.
I think it was rationalised after the introduction and the hack was quickly
lost (but my memory can be wrong).
D
Dik T. Winter
Not in *floating-point*. Rounding can be different. Consider the following
code given some (positive) a and b with a > b where the requirement is that
after the operations
c == a + b (rounded)
c + cc == a + b (mathematically)
the code reads:
c = a + b;
cc = a - c + b;
Now cc contains the *exact* error made during rounding.
D
Dik T. Winter
This example was obviously not quite identical. So now I will show you a
case where the expression above will be different. Suppose double precision,
a 53 bit mantissa, round to nearest, IEEE. Set b = 2**52 + 1, a = 0.5.
b - a will produce 2**52 because of the rounding rules (when halfway, round
to even). 2**52 + a will for the same rules also produce 2**52, so the
result is not equal to b.
(The subrule: "when halfway round to even" produces a large number of
unexpected results.)
Now this example obviously only works when there is no extended precision
used for intermediate arithmetic. I am quite sure examples can be found
that also work when x86 extended arithmetic is used.
D
Dik T. Winter
This example is of course much better than what I have given.
L
lawrence.jones
Keith Thompson said:
No, I think using unary + to enforce order of evaluation was a committee
invention (and a not very good one, which is why it didn't make it into
the standard). I don't remember whether unary + was proposed on its own
for symmetry before the evaluation ordering proposal or if it was just a
secondary reason for adopting it. In any event, there's nothing that
says the committee has to document their mistakes.
C
CBFalconer
pete said:
Fair enough, if you include floats, which are always intrinsically
approximations. I was considering integral value only.
K
Keith Thompson
CBFalconer said:
So you didn't see the phrase "and so in floating-point" in Dik's
article? You even quoted it.
D
Dik T. Winter
No. The standard states that if something is not "always false" it can
not treat it as "always false". And (due to rounding) there are examples
where it is true.
D
Dik T. Winter
If my memory is right (I was not a participant, only read about it in the
newsgroup net.lang.c), at that time there was not yet a committee, only
discussions at Usenix conferences.
From what I remember, it was the primary reason. There had been complaints
from numerical mathematicians that it was impossible to impose order of
evalutation except by using temporaries. At that time the people trying to
get to a standard did not understand their complaint and so as a quick hack
added the unary plus. The rationale was symmetry. Later there was opposition
with people that wished to add ^^ for the same reason, or otherwise remove
the unary plus because it could all be done by temporaries.
The final result was that order of evaluation should honour the parenthesis,
unless the expression would not *numerically* depend on it. For some reason
the unary plus was kept in (for symmetry reasons) and the ^^ was left out
because it was not useful.
> In any event, there's nothing that
> says the committee has to document their mistakes.
Indeed.
C
CBFalconer
Keith said:
Because I didn't pay attention. Sorry.
D
Dik T. Winter
Why then did you ask your question in response to something that was
about floating-point? Did you actually *read* the line before
"a + (b - a) can not be rearranged at all"?