C PROGRAMMING

Chapter 7: More Operators

In this chapter we'll meet some (though still not all) of C's more advanced arithmetic operators. The ones we'll meet here have to do with making common patterns of operations easier.

It's extremely common in programming to have to increment a variable by 1, that is, to add 1 to it. (For example, if you're processing each element of an array, you'll typically write a loop with an index or pointer variable stepping through the elements of the array, and you'll increment the variable each time through the loop.) The classic way to increment a variable is with an assignment like

i = i + 1

Such an assignment is perfectly common and acceptable, but it has a few slight problems:

1. As we've mentioned, it looks a little odd, especially from an algebraic perspective.
2. If the object being incremented is not a simple variable, the idiom can become cumbersome to type, and correspondingly more error-prone. For example, the expression

   a[i+j+2*k] = a[i+j+2*k] + 1
   

   is a bit of a mess, and you may have to look closely to see that the similar-looking expression

   a[i+j+2*k] = a[i+j+2+k] + 1
   

   probably has a mistake in it.
3. Since incrementing things is so common, it might be nice to have an easier way of doing it.

In fact, C provides not one but two other, simpler ways of incrementing variables and performing other similar operations.

7.1 Assignment Operators

[This section corresponds to K&R Sec. 2.10]

The first and more general way is that any time you have the pattern

v = v op e

where v is any variable (or anything like a[i]), op is any of the binary arithmetic operators we've seen so far, and e is any expression, you can replace it with the simplified

v op= e

For example, you can replace the expressions

i = i + 1
 j = j - 10
 k = k * (n + 1)
 a[i] = a[i] / b

with

i += 1
 j -= 10
 k *= n + 1
 a[i] /= b

In an example in a previous chapter, we used the assignment

a[d1 + d2] = a[d1 + d2] + 1;

to count the rolls of a pair of dice. Using +=, we could simplify this expression to

a[d1 + d2] += 1;

As these examples show, you can use the ``op='' form with any of the arithmetic operators (and with several other operators that we haven't seen yet). The expression, e, does not have to be the constant 1; it can be any expression. You don't always need as many explicit parentheses when using the op= operators: the expression

k *= n + 1

is interpreted as

k = k * (n + 1)

7.2 Increment and Decrement Operators

[This section corresponds to K&R Sec. 2.8]

The assignment operators of the previous section let us replace v = v op e with v op= e, so that we didn't have to mention v twice. In the most common cases, namely when we're adding or subtracting the constant 1 (that is, when op is + or - and e is 1), C provides another set of shortcuts: the autoincrement and autodecrement operators. In their simplest forms, they look like this:

++i  add 1 to i
 --j  subtract 1 from j

These correspond to the slightly longer i += 1 and j -= 1, respectively, and also to the fully ``longhand'' forms i = i + 1 and j = j - 1.

The ++ and -- operators apply to one operand (they're unary operators). The expression ++i adds 1 to i, and stores the incremented result back in i. This means that these operators don't just compute new values; they also modify the value of some variable. (They share this property--modifying some variable--with the assignment operators; we can say that these operators all have side effects. That is, they have some effect, on the side, other than just computing a new value.)

The incremented (or decremented) result is also made available to the rest of the expression, so an expression like

k = 2 * ++i

means ``add one to i, store the result back in i, multiply it by 2, and store that result in k.'' (This is a pretty meaningless expression; our actual uses of ++ later will make more sense.)

Both the ++ and -- operators have an unusual property: they can be used in two ways, depending on whether they are written to the left or the right of the variable they're operating on. In either case, they increment or decrement the variable they're operating on; the difference concerns whether it's the old or the new value that's ``returned'' to the surrounding expression. The prefix form ++i increments i and returns the incremented value. The postfix form i++ increments i, but returns the prior, non-incremented value. Rewriting our previous example slightly, the expression

k = 2 * i++

means ``take i's old value and multiply it by 2, increment i, store the result of the multiplication in k.''

The distinction between the prefix and postfix forms of ++ and -- will probably seem strained at first, but it will make more sense once we begin using these operators in more realistic situations.

For example, our getline function of the previous chapter used the statements

line[nch] = c;
 nch = nch + 1;

as the body of its inner loop. Using the ++ operator, we could simplify this to

line[nch++] = c;

We wanted to increment nch after deciding which element of the line array to store into, so the postfix form nch++ is appropriate.

Notice that it only makes sense to apply the ++ and -- operators to variables (or to other ``containers,'' such as a[i]). It would be meaningless to say something like

1++

or

(2+3)++

The ++ operator doesn't just mean ``add one''; it means ``add one to a variable'' or ``make a variable's value one more than it was before.'' But (1+2) is not a variable, it's an expression; so there's no place for ++ to store the incremented result.

Another unfortunate example is

i = i++;

which some confused programmers sometimes write, presumably because they want to be extra sure that i is incremented by 1. But i++ all by itself is sufficient to increment i by 1; the extra (explicit) assignment to i is unnecessary and in fact counterproductive, meaningless, and incorrect. If you want to increment i (that is, add one to it, and store the result back in i), either use

i = i + 1;
or
 i += 1;
or
 ++i;
or
 i++;

Don't try to use some bizarre combination.

Did it matter whether we used ++i or i++ in this last example? Remember, the difference between the two forms is what value (either the old or the new) is passed on to the surrounding expression. If there is no surrounding expression, if the ++i or i++ appears all by itself, to increment i and do nothing else, you can use either form; it makes no difference. (Two ways that an expression can appear ``all by itself,'' with ``no surrounding expression,'' are when it is an expression statement terminated by a semicolon, as above, or when it is one of the controlling expressions of a for loop.) For example, both the loops

for(i = 0; i < 10; ++i)
  printf("%d\n", i);

and

for(i = 0; i < 10; i++)
  printf("%d\n", i);

will behave exactly the same way and produce exactly the same results. (In real code, postfix increment is probably more common, though prefix definitely has its uses, too.)

In the preceding section, we simplified the expression

a[d1 + d2] = a[d1 + d2] + 1;

from a previous chapter down to

a[d1 + d2] += 1;

Using ++, we could simplify it still further to

a[d1 + d2]++;

or

++a[d1 + d2];

(Again, in this case, both are equivalent.)

We'll see more examples of these operators in the next section and in the next chapter.

7.3 Order of Evaluation

[This section corresponds to K&R Sec. 2.12]

When you start using the ++ and -- operators in larger expressions, you end up with expressions which do several things at once, i.e., they modify several different variables at more or less the same time. When you write such an expression, you must be careful not to have the expression ``pull the rug out from under itself'' by assigning two different values to the same variable, or by assigning a new value to a variable at the same time that another part of the expression is trying to use the value of that variable.

Actually, we had already started writing expressions which did several things at once even before we met the ++ and -- operators. The expression

(c = getchar()) != EOF

assigns getchar's return value to c, and compares it to EOF. The ++ and -- operators make it much easier to cram a lot into a small expression: the example

line[nch++] = c;

from the previous section assigned c to line[nch], and incremented nch. We'll eventually meet expressions which do three things at once, such as

a[i++] = b[j++];

which assigns b[j] to a[i], and increments i, and increments j.

If you're not careful, though, it's easy for this sort of thing to get out of hand. Can you figure out exactly what the expression

a[i++] = b[i++];  /* WRONG */

should do? I can't, and here's the important part: neither can the compiler. We know that the definition of postfix ++ is that the former value, before the increment, is what goes on to participate in the rest of the expression, but the expression a[i++] = b[i++] contains two ++ operators. Which of them happens first? Does this expression assign the old ith element of b to the new ith element of a, or vice versa? No one knows.

When the order of evaluation matters but is not well-defined (that is, when we can't say for sure which order the compiler will evaluate the various dependent parts in) we say that the meaning of the expression is undefined, and if we're smart we won't write the expression in the first place. (Why would anyone ever write an ``undefined'' expression? Because sometimes, the compiler happens to evaluate it in the order a programmer wanted, and the programmer assumes that since it works, it must be okay.)

For example, suppose we carelessly wrote this loop:

int i, a[10];
 i = 0;
 while(i < 10)
  a[i] = i++;   /* WRONG */

It looks like we're trying to set a[0] to 0, a[1] to 1, etc. But what if the increment i++ happens before the compiler decides which cell of the array a to store the (unincremented) result in? We might end up setting a[1] to 0, a[2] to 1, etc., instead. Since, in this case, we can't be sure which order things would happen in, we simply shouldn't write code like this. In this case, what we're doing matches the pattern of a for loop, anyway, which would be a better choice:

for(i = 0; i < 10; i++)
  a[i] = i;

Now that the increment i++ isn't crammed into the same expression that's setting a[i], the code is perfectly well-defined, and is guaranteed to do what we want.

In general, you should be wary of ever trying to second-guess the order an expression will be evaluated in, with two exceptions:

1. You can obviously assume that precedence will dictate the order in which binary operators are applied. This typically says more than just what order things happens in, but also what the expression actually means. (In other words, the precedence of * over + says more than that the multiplication ``happens first'' in 1 + 2 * 3; it says that the answer is 7, not 9.)
2. Although we haven't mentioned it yet, it is guaranteed that the logical operators && and || are evaluated left-to-right, and that the right-hand side is not evaluated at all if the left-hand side determines the outcome.

To look at one more example, it might seem that the code

int i = 7;
 printf("%d\n", i++ * i++);

would have to print 56, because no matter which order the increments happen in, 7*8 is 8*7 is 56. But ++ just says that the increment happens later, not that it happens immediately, so this code could print 49 (if the compiler chose to perform the multiplication first, and both increments later). And, it turns out that ambiguous expressions like this are such a bad idea that the ANSI C Standard does not require compilers to do anything reasonable with them at all. Theoretically, the above code could end up printing 42, or 8923409342, or 0, or crashing your computer.

Programmers sometimes mistakenly imagine that they can write an expression which tries to do too much at once and then predict exactly how it will behave based on ``order of evaluation.'' For example, we know that multiplication has higher precedence than addition, which means that in the expression

i + j * k

j will be multiplied by k, and then i will be added to the result. Informally, we often say that the multiplication happens ``before'' the addition. That's true in this case, but it doesn't say as much as we might think about a more complicated expression, such as

i++ + j++ * k++

In this case, besides the addition and multiplication, i, j, and k are all being incremented. We can not say which of them will be incremented first; it's the compiler's choice. (In particular, it is not necessarily the case thatj++ or k++ will happen first; the compiler might choose to save i's value somewhere and increment i first, even though it will have to keep the old value around until after it has done the multiplication.)

In the preceding example, it probably doesn't matter which variable is incremented first. It's not too hard, though, to write an expression where it does matter. In fact, we've seen one already: the ambiguous assignmenta[i++] = b[i++]. We still don't know which i++ happens first. (We can not assume, based on the right-to-left behavior of the = operator, that the right-hand i++ will happen first.) But if we had to know what a[i++] = b[i++] really did, we'd have to know which i++ happened first.

Finally, note that parentheses don't dictate overall evaluation order any more than precedence does. Parentheses override precedence and say which operands go with which operators, and they therefore affect the overall meaning of an expression, but they don't say anything about the order of subexpressions or side effects. We could not ``fix'' the evaluation order of any of the expressions we've been discussing by adding parentheses. If we wrote

i++ + (j++ * k++)

we still wouldn't know which of the increments would happen first. (The parentheses would force the multiplication to happen before the addition, but precedence already would have forced that, anyway.) If we wrote

(i++) * (i++)

the parentheses wouldn't force the increments to happen before the multiplication or in any well-defined order; this parenthesized version would be just as undefined as i++ * i++ was.

There's a line from Kernighan & Ritchie, which I am fond of quoting when discussing these issues [Sec. 2.12, p. 54]:

The moral is that writing code that depends on order of evaluation is a bad programming practice in any language. Naturally, it is necessary to know what things to avoid, but if you don't know how they are done on various machines, you won't be tempted to take advantage of a particular implementation.

The first edition of K&R said

...if you don't know how they are done on various machines, that innocence may help to protect you.

I actually prefer the first edition wording. Many textbooks encourage you to write small programs to find out how your compiler implements some of these ambiguous expressions, but it's just one step from writing a small program to find out, to writing a real program which makes use of what you've just learned. But you don't want to write programs that work only under one particular compiler, that take advantage of the way that one compiler (but perhaps no other) happens to implement the undefined expressions. It's fine to be curious about what goes on ``under the hood,'' and many of you will be curious enough about what's going on with these ``forbidden'' expressions that you'll want to investigate them, but please keep very firmly in mind that, for real programs, the very easiest way of dealing with ambiguous, undefined expressions (which one compiler interprets one way and another interprets another way and a third crashes on) is not to write them in the first place.