Equivalence of “a @= b” and “a = a @ b”

Question

It\'s often mooted (indeed I think even the standard alludes to it), that a @= b and a = a @ b are equivalent. Here I\'m using @ to stand

Answer 1

You are correct. Actually, they are not even guaranteed to be equivalent in the general non-atomic case, as a class could provided different overloads for += and + which are completely independent.

Answer 2

The built-in operators have that equivalence, except that a @= b only evaluates a once, while a = a @ b evaluates it twice.

However, these are not the built-in operators, but overloads provided by the standard library. They are treated as separate, unrelated functions, so the compiler cannot change one into the other. (In fact, as noted in the comments, only the assignment operators are overloaded for atomic types - you would have to explicitly load and store the value to use the non-atomic form).

Answer 3

You can define ^= and ^ to do completely different things. So, no compiler can't change one to the another just if it wants

Answer 4

The language standard only defines the behavior of the built-in operators, not the "user defined" overloads. And from a language point of view, there is no built-in operator for std::atomic_int (which is formally a "user defined type"); std::atomic_int is a typedef for std::atomic<int>, which defines a number of operator@= overloads, but no simple @. So for

std::atomic_int i;
i ^= 1;

the second line becomes:

i.operator^=( 1 );

but for:

std::atomic_int i;
i = i ^ 1;

the second line becomes:

i.operator=( i.operator int() ^ 1 );

One could argue that this is part of what is implied by "the left hand argument being evaluated twice, instead of once". More generally, however, the definitions for overloaded operators are whatever the author of the operator wanted: operator+= could (as far as the language is concerned) actually subtract, even when operator+ added. (I've a couple of cases where operator+ actually does operator+=. This is not usually a good idea, and in my case, it only happens with classes specially designed for use with std::accumulate, and documented to only be used in that case.) The standard simply doesn't restrict user defined operators