What does =+ (equals-plus) mean in C?
I came across =+
as opposed to the standard +=
today in some C code; I'm not qu开发者_开发技巧ite sure what's going on here. I also couldn't find it in the documentation.
In ancient versions of C, =+
was equivalent to +=
. Remnants of it have been found alongside the earliest dinosaur bones.
For example, B introduced generalized assignment operators, using
x+=y
to addy
tox
. The notation came from Algol 68 via McIlroy, who incorporated it in his version of TMG. (In B and early C, the operator was spelled=+
instead of+=
; this mistake, repaired in 1976, was induced by a seductively easy way of handling the first form in B's lexical analyzer.)
[The Development of the C Language, Dennis Ritchie. Copyright ACM, 1993. Internal citations omitted.]
Since the mid-1970's, it has no special meaning -- it's just a =
followed by a +
.
You can find evidence of the old notation in the 7th Edition UNIX Manual (Vol 2a) dated January 1979, available online at http://cm.bell-labs.com/7thEdMan/ (unavailable since approximately July 2015; the June 2015 version is now available via the WayBack Machine at http://cm.bell-labs.com/7thEdMan/ — or at https://9p.io/7thEdMan/).
The chapter is titled 'C Reference Manual' by Dennis M. Ritchie, and is in the PDF version of the manual, but not in the HTML version. In the relevant part, it says:
7.14.1 lvalue = expression
The value of the expression replaces that of the object referred to by the lvalue. The operands need not have the same type, but both must be int, char, float, double, or pointer. If neither operand is a pointer, the assignment takes place as expected, possibly preceded by conversion of the expression on the right. When both operands are int or pointers of any kind, no conversion ever takes place; the value of the expression is simply stored into the object referred to by the lvalue. Thus it is possible to generate pointers which will cause addressing exceptions when used.
7.14.2 lvalue =+ expression
7.14.3 lvalue =- expression
7.14.4 lvalue =* expression
7.14.5 lvalue =/ expression
7.14.6 lvalue =% expression
7.14.7 lvalue =>> expression
7.14.8 lvalue =<< expression
7.14.9 lvalue =& expression
7.14.10 lvalue =^ expression
7.14.11 lvalue = | expressionThe behavior of an expression of the form ‘‘E1 =op E2’’ may be inferred by taking it as equivalent to ‘‘E1 = E1 op E2’’; however, E1 is evaluated only once. Moreover, expressions like ‘‘i =+ p’’ in which a pointer is added to an integer, are forbidden.
Separately, there is a paper 'Evolution of C' by L Rosler in the 'UNIX® SYSTEM: Readings and Applications, Volume II', originally published by AT&T as their Technical Journal for October 1984, later published in 1987 by Prentice-Hall (ISBN 0-13-939845-7). One section of that is:
III. Managing Incompatible Changes
Inevitably, some of the changes that were made alter the semantics of existing valid programs. Those who maintain the various compilers used internally try to ensure that programmers have adequate warning that such changes are to take effect, and that the introduction of a new compiler release does not force all programs to be recompiled immediately.
For example, in the earliest implementations the ambiguous expression
x=-1
was interpreted to mean "decrement x by 1". It is now interpreted to mean "assign the value -1 to x". This change took place over the course of three annual major releases. First, the compiler and thelint
program verifier were changed to generate a message warning about the presence of an "old-fashioned" assignment operation such as=-
. Next, the parsers were changed to the new semantics, and the compilers warned about an ambiguous assignment operation. Finally, the warning messages were eliminated.Support for the use of an "old-fashioned initialization"
int x 1;
(without an equals sign) was dropped by a similar strategy. This helps the parser produce more intelligent syntax-error diagnostics.
Predictably, some C users ignored the warnings until introduction of the incompatible compilers forced them to choose between changing their obsolete source code or assuming maintenance of their own versions of the compiler. But on the whole the strategy of phased change was successful.
Also, in Brian W Kernighan and Dennis M Ritchie The C Programming Language, 1st Edn (1978), on p212 in Appendix A, §17 Anachronisms, it says:
Earlier versions of C used the form
=op
instead ofop=
for assignment operators. This leads to ambiguities, typified by:x=-1
which actually decrements
x
since the=
and the-
are adjacent, but which might easily be meant to assign-1
tox
.
It's just assignment followed by unary plus.
#include <stdio.h>
int main() {
int a;
a =+ 5;
printf("%d\n",a);
return 0;
}
Prints "5". Change a =+ 5
to a =- 5
and it prints "-5". An easier way to read a =+ 5
is probably a = +5
.
It's an ancient defunct variant of +=
. In modern compilers, this is equivalent to an assignment operator followed by a unary +
.
I think
a =+ 5;
should be equivalent to
a = (+5);
and therefore be code of very bad style.
I tried the following code and it printed "5":
#include <iostream>
using namespace std;
int main()
{
int a=2;
a =+ 5;
cout << a;
}
After reading your question I just investigated on these. Let me tell you what I have found. Tried it on gcc and turboc. Did not make it sure on Visual Studio as I have not installed it on my pC
int main()
{
int a=6;
a =+ 2;
printf("%d",a);
} o/p , a value is 2
int main()
{
int a=6;
a =- 2;
printf("%d",a);
} o/p , a value is -2
I dont know about the other answers as they said its an ancient version of C.But the modern compilers treat them as a value to be assigned ( thats positive or negative nothing more than that) and these below code makes me more sure about it.
int main()
{
int a=6;
a =* 2; \\ Reporting an error inavlid type of argument of unary *
printf("%d",a);
}
if *= is equal to =* then it should not report error but its throwing an error
using "=+" you are just assigning the operand is positive for example int a = +10; same as for negative number int a = -10;
精彩评论