I came across =+
as opposed to the standard +=
today in some C code; I'm not quite sure what's going on here. I also couldn't find it in the documentation.

- 26,597
- 4
- 30
- 62

- 4,228
- 9
- 50
- 79
-
2Does that piece of code work as expected? If not, that may be a typo. – Mark Jones Sep 27 '11 at 18:33
-
@TimCooper pretty sure, its in a lot of lines and the code compiles fine. I'm using microsoft visual studios – mugetsu Sep 27 '11 at 18:33
-
Of course it compiles. Does it work as expected when executed? – Mark Jones Sep 27 '11 at 18:34
-
I wouldn't trust a compiler that didn't warn me that something's fishy going around there. – darioo Sep 27 '11 at 18:37
-
There are two interpretations below. I am curious which one Visual Studio is treating these as. Is it += or = (+)? – Steve Rowe Sep 27 '11 at 19:04
-
@SteveRowe: `=+`. I'm tempted to dare anyone to link to code using `=+` to mean `+=` (that isn't a history lesson). – user786653 Sep 27 '11 at 19:35
-
3@SteveRowe: VS (like any compiler since the earth cooled) treats it as = (+). – Jerry Coffin Sep 27 '11 at 22:02
-
6I just can't see why these interesting -- but fundamentally trivial, pure entertainment -- questions always get a lot of attention (and "thumb ups") with *dozens* of *identical* answers, whereas people asking serious stuff often have its question ignored, and 0 answers. Answering trivial questions requires no effort. Let's answer hard ones. – gd1 Sep 28 '11 at 14:26
-
4@gd1: it's perhaps the biggest flaw in the StackExchange model. Not only are such questions popular, they usually contradict the guideline that questions should be "based on actual problems that you face" ([faq#dontask]), making the guideline ridiculously dissonant with the community's actual use of the site. In short, the least useful questions are given the highest scores - exactly the opposite of the purpose of voting. I raised this on meta but was shot down. – Igby Largeman Oct 26 '11 at 18:51
7 Answers
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 +
.

- 476,176
- 80
- 629
- 1,111
-
17But it's not supported any more because it's ambiguous with unary +. – Paul Tomblin Sep 27 '11 at 18:34
-
1Do you have a citation for this? I don't see it in "C A Reference Manual", which is usually pretty authoritative. – markgz Sep 27 '11 at 18:41
-
3I can confirm that `=+` was originally the same as the current `+=`. I don't recall if both were valid from the start or `=+` was the only option initially, but in any event it was (quite rightly) dropped because of the ambiguity. – Hot Licks Sep 27 '11 at 18:48
-
3It may have only been a VAX thing but I swear I was taught += was preincrement, and =+ was post increment, which as I remember we almost always the exact same thing... but not in complex Order of Operation issues. – Eric Brown - Cal Sep 27 '11 at 21:38
-
In ancient version of c =+ may be += . But still =+ is valid operation in c, yes it assigns a positive value to the variable at left had side. – MCG Sep 27 '11 at 21:53
-
8@markgz: see page 5 of Dennis's [paper](http://www.lysator.liu.se/c/chistory.ps) (warning:Postscript) on the history of C. – Jerry Coffin Sep 27 '11 at 21:56
-
3Thanks, Jerry. For those interested, the paper says the following about "=+": "...this mistake, repaired in 1976...". 1976 was before my time. – markgz Sep 27 '11 at 23:22
-
2@MCG: In modern C (or C++), `c =+ x;` assigns the value of `x` (positive or negative) to `c` (`c = +x;`). It does not change a negative value of `x` to a positive value. The `+` is a no-op. – Jonathan Leffler Sep 28 '11 at 06:49
-
What is the shortest distance between `=+` in a code repository and a location where dinosaur bones were discovered? – Eric Postpischil Feb 23 '21 at 19:24
-
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
.

- 730,956
- 141
- 904
- 1,278
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
.

- 29,780
- 4
- 43
- 53
-
1That test needs to initialise *a* to something other than zero. If you use `int a = 3;` do you get the same result? – Hand-E-Food Sep 28 '11 at 00:38
-
@Hand-E-Food: his test doesn't initialize `a` to zero or any other value, actually. – Kip Sep 29 '11 at 17:23
-
It wasn't meant as a test. The reason I put the initialization of `a` on it's own line was to make it more similar to what I thought it might look like in OPs source code - I should perhaps have put `/*other code*/` between the declaration and assignment. – user786653 Sep 29 '11 at 18:36
It's an ancient defunct variant of +=
. In modern compilers, this is equivalent to an assignment operator followed by a unary +
.

- 129,958
- 22
- 279
- 321

- 6,514
- 8
- 32
- 37
-
-
Deprecated is more "standardese" than English. "Defunct" is better because it implies that it doesn't work (which it doesn't in modern C implementations); deprecated implies it's still supported but will be removed or deleted in the future. – CB Bailey Sep 27 '11 at 18:55
-
I don't think either "deprecated" or "defunct" or even "obsolete" are correct descriptions. The problem is that the code `a =+ 5` is entirely valid C in the modern standard, but it is not semantically equivalent to `a += 5` (if it ever was - I'll take your word for that, but I've been using C since 1989). If @mugetsu has seen this code it is more likley that it is a typo (resulting in a bug) than just old code. – Clifford Sep 27 '11 at 19:36
-
@onemasse: My point was to be clear that this syntax is valid, but does not have the same meaning as `+=`, it is therefore not deprecated or obsolete, but rather simply an ill-advised coding style. – Clifford Sep 28 '11 at 08:37
-
@Clifford I've clarified. Even though it's most likely a typo, I think there's a point in mentioning other explanations. I don't think we should rule out the possibility that somebody searching through SO have found a listing of ancient C code. Also, if you know the history behind it, I think you can understand better why to avoid writing '=+' instead of just '='. Not only is it meaningless, but it's also confusing. What kind of typo is it? Maybe it's meant to be an assignment followed by a plus, or maybe the characters are swapped. – onemasse Sep 28 '11 at 10:43
-
Deprecated means "it still works but you should not be using it". The old notation does not work as before; it is not merely deprecated but obsolete or defunct. – Jonathan Leffler Sep 28 '11 at 18:50
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;
}

- 5,793
- 4
- 40
- 69
using "=+" you are just assigning the operand is positive for example int a = +10; same as for negative number int a = -10;

- 417
- 5
- 10
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

- 9,285
- 27
- 84
- 131