Gotcha #15: Precedence Problems

This item doesn't speak to the issue of whether the Countess or the Baroness should sit next to the Ambassador at dinner (that problem has no solution). No, here we're going to discuss how the many levels of operator precedence in C++ expressions can give rise to some irksome 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.)