Gotcha #15: Precedence Problems

Precedence and Associativity

It's usually beneficial for a programming language to have different levels of operator precedence, since this allows simplification of complex expressions without excessive and distracting use of parentheses. (Note, however, that it's usually a good idea to parenthesize complex or obscure expressions that may not be easily understood by all readers. Nevertheless, it's usually clearest to omit unnecessary parentheses in simple, universally understood cases.)

a = a + b * c; 

In the expression above, we know that * has the highest precedence, or binding strength, so we'll execute that operation first. Assignment has the lowest precedence, so we'll perform that operation last.

b = a = a + b + c; 

In this case, we know we'll perform the additions before the assignments, since + has higher precedence than =, but which addition and which assignment will be performed first? Here we have to examine the associativity of the operators. In C++, operators can be left-associative or right-associative. A left-associative operator like + will bind first with the argument to its left. Therefore, we'll first add a and b before adding the result of that subexpression to c.

Assignment is right-associative, so we'll first assign the result of a+b+c to a, then assign a to b. Some languages contain nonassociative operators; it would be illegal to have an expression like a@b@c if @ were a nonassociative operator. Congenial language that it is, C++ has no nonassociative operators.

Precedence Problems

The iostream library is designed to allow a minimum of parentheses:

cout << "a+b = " << a+b << endl; 

The + operator has higher precedence than the left shift operator, so we get the desired parse; a+b is calculated first, then the result is sent to cout.

cout << a ? f() : g(); 

Here, the use of C++'s only ternary operator gets us into trouble, but it's not that ?: is ternary; it's that it has lower precedence than <<. Therefore, we're asking the compiler to generate code to shift a to cout, then use the result of that expression as the condition in the ?:. The tragic aspect of this situation is that the code is perfectly legal! (An output stream object like cout has a member operator void * that can be used implicitly to convert it to a void * value, which in turn can be converted to false or true, depending on whether the pointer value is null or not.) Here's a case where we reach for our parentheses:

cout << (a ? f() : g()); 

If you want to be considered completely normal, you can take things a step further:

if( a ) 
   cout << f();
else
   cout << g();

This approach doesn't have the same je ne sais quoi of the previous one, but it does have the advantage of being clear and maintainable.

Not many C++ programmers are fooled by precedence problems with pointers to classes, since it's well known that the -> and . operators have very high precedence. Therefore, an expression like a = ++ptr->mem means to increment the member mem of the object to which ptr refers. If we'd wanted to increment the pointer first, we'd have written a = (++ptr)->mem, or potentially ++ptr; a = ptr->mem;, or, on a really bad day, a = (++ptr, ptr->mem).

Pointers to class members are a different story. They must be dereferenced in the context of a class object (see Gotcha #46). For this purpose, two special-purpose dereference operators are defined: ->* to dereference a pointer to member with a pointer to a class object and .* to dereference a pointer to member with a class object.

Pointers to member functions are often a headache, but they don't cause any serious syntax problems:

class C { 
   // . . .
   void f( int );
   int mem;
};
void (C::*pfmem)(int) = &C::f;
int C::*pdmem = &C::mem;
C *cp = new C;
// . . .
cp->*pfmem(12); // error!

We get a compile-time error because the function call operator has higher precedence than the ->* operator, but we can't call a pointer to member function without dereferencing it first. Parentheses are required here:

(cp->*pfmem)(12); 

Pointers to data members are more problematic. Consider the following expression:

a = ++cp->*pdmem 

The variable cp is the same pointer to class object above, and pdmem is not a member name but a pointer to member. In this case, because ->* has lower precedence than ++, cp will be incremented before the pointer to member is dereferenced. Unless cp is pointing into an array of class objects, this is likely to result in a bad dereference.

Pointers to class members are not well understood by many C++ programmers. For the future viability of the maintenance of your code, keep things as simple and straightforward as possible when using them:

++cp; 
a = cp->*pdmem;

Associativity Problems

Most C++ operators are left-associative, and C++ has no nonassociative operators. This doesn't stop some otherwise intelligent programmers from trying to use operators that way:

int a = 3, b = 2, c = 1; 
// . . .
if( a > b > c ) // legal, but probably wrong . . .

This code is perfectly legal but probably wrong. The value of the expression 3>2>1 is, of course, false. The greater-than operator, like most C++ operators, is left-associative, so we'll first evaluate the subexpression 3>2, which is true. That leaves us with the expression true>1. We convert true to an integer and evaluate the expression 1>1, which is false.

In this case, it's likely the programmer meant to write the condition as a>b && b>c. If, for some obscure reason, the programmer actually wanted the original result, a better way to write the condition would be a>b?1>c:0>c or perhaps (c-(a>b))<0, either of which is strange enough to cause a maintainer to take a second look. In this case, a comment would be permissible as well. (See Gotcha #1.)