When Did "And" Become an Operator in C++

When did and become an operator in C++

There are several such alternatives defined in C++. You can probably use switches to turn these on/off.

How has += operator been implemented in c++?

Operators are not generated from others (except with/from <=> in C++20):

providing operator < doesn't allow a > b (which is indeed "logically" equivalent to b < a). You have to implement all (even by re-using some).

For classes, a += b is not a shorthand for a = a + b

but for a.operator +=(b) or operator +=(a, b)

In the same way a = a + b is a shorthand for a.operator=(operator +(a, b)) (or its variant)

In practice, it is more efficient to implement operator+ from operator += than the reverse.

Even if a user might expect similar behavior according to their names, they are regular functions.

I already saw a matrix iterator for which ++it increase column index whereas it++ increase row index.

If += were simply a shorthand for a = a + <rhs of +=> overloading + operator should also implicitly overload +=, unless explicitly overloaded otherwise. But that isn't what happens. That means, a += b doesn't get converted to a = a + b.

(Possible) rational to not generate might be performance and control:

Vector (for math) or Matrix are good example:

4 possible overloads

Matrix operator+(Matrix&& lhs, Matrix&& rhs)      { return std::move(lhs += rhs); }
Matrix operator+(Matrix&& lhs, const Matrix& rhs) { return std::move(lhs += rhs); }
Matrix operator+(const Matrix& lhs, Matrix&& rhs) { return std::move(rhs += lhs); } // + is symmetrical :)
Matrix operator+(const Matrix& lhs, const Matrix& rhs) { auto tmp{lhs}; return tmp += rhs; }

Side effect of the decision allow to give different meanings to operators, as "name operator":

if (42 <in> std::vector{4, 8, 15, 16, 23, 42})

What is the -- operator in C++?

--> is not an operator. It is in fact two separate operators, -- and >.

The conditional's code decrements x, while returning x's original (not decremented) value, and then compares the original value with 0 using the > operator.

To better understand, the statement could be written as follows:

while( (x--) > 0 )

Operator precedence versus order of evaluation

I would prefer an explanation that uses function calls. A function call makes it very obvious that "something needs to be evaluated before applying the operator".

Basic example:

int x = a() + b() * c();

must be calculated as

temp = result_of_b_func_call * result_of_c_func_call
x = result_of_a_func_call + temp

due to multiplication having higher precedence than addition.

However, the evaluation order of the 3 function calls is unspecified, i.e. the functions can be called in any order. Like

a(), b(), c()
or
a(), c(), b()
or
b(), a(), c()
or
b(), c(), a()
or
c(), a(), b()
or
c(), b(), a()

Another basic example would be to explain operator associativity - like:

int x = a() + b() + c();

must be calculated as

temp = result_of_a_func_call + result_of_b_func_call
x = temp + result_of_c_func_call

due to left-to-right associativity of addition. But again the order of the 3 function calls are unknown.

If function calls is not an option, I would prefer something like

x = a * b + c / d

Here it's pretty obvious that there are two sub-expressions, i.e. a * b and c / d. Due to operator precedence both of these sub-expressions must be evaluated before the addition but the order of evaluation is unspecified, i.e. we can't tell whether the multiplication or the division is done first.

So it can be

temp1 = a * b
temp2 = c / d
x = temp1 + temp2

or it can be

temp2 = c / d
temp1 = a * b
x = temp1 + temp2

All we know is that the addition must be last.

printf tilde operator in c

The ~ operator simply inverts all bits in a number.

On most modern compilers, int is 32 bits in size, and a signed int uses 2's complement representation. Which means, among other things, that the high bit is reserved for the sign, and if that bit is 1 then the number is negative.

0 and 7 are int literals. Assuming the above, we get these results:

• 0 is bits 00000000000000000000000000000000b
  
  = 0 when interpreted as either signed int or unsigned int

• ~0 is bits 11111111111111111111111111111111b
  
  = -1 when interpreted as signed int
  
  = 4294967285 when interpreted as unsigned int

• 7 is bits 00000000000000000000000000000111b
  
  = 7 when interpreted as either signed int or unsigned int

• ~7 is bits 11111111111111111111111111111000b
  
  = -8 when interpreted as signed int
  
  = 4294967288 when interpreted as unsigned int

In your printf() statements, %d interprets its input as a signed int, and %u interprets as an unsigned int. This is why you are seeing the results you get.

What is the difference between += and =+ C assignment operators

In modern C, or even moderately ancient C, += is a compound assignment operator, and =+ is parsed as two separate tokens. = and +. Punctuation tokens are allowed to be adjacent.

So if you write:

x += y;

it's equivalent to

x = x + y;

except that x is only evaluated once (which can matter if it's a more complicated expression).

If you write:

x =+ y;

then it's parsed as

x = + y;

and the + is a unary plus operator.

Very early versions of C (around the mid 1970s, before the publication of K&R1 in 1978) used different symbols for compound assignments. Where modern C uses +=, early C used =+. Early C had no unary + operator, but it did have a unary - operator, and the use of =- caused problems; programmers would write x=-y intending it to mean x = -y, but it was silently interpreted as x =- y. The language was changed some time between 1975 and 1978 to avoid that problem. As late as 1999, I worked with a compiler (VAXC on VMS) that would warn about an ambiguous use of =-, but would use the older meaning. That shouldn't be a concern now unless you're a hobbyist playing with some very old software and/or hardware.

(A 1975 C Reference Manual shows the old =-, =+, et al forms of the compound assignment operators. The first edition of The C Programming Language by Kernighan and Ritchie, published in 1978, shows the modern -=, +=, et al, but mentions the older forms under "Anachronisms".)

---

Related Topics