What does =+ mean in C?

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.

Solution 1:

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 add y to x. 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 +.

Solution 2:

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 = | expression

The 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 the lint 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.

Earlier versions of C used the form =op instead of op= 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 to x.

Solution 3:

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.

Solution 4:

It's an ancient defunct variant of +=. In modern compilers, this is equivalent to an assignment operator followed by a unary +.

Solution 5:

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;
}