Gotcha #16: for Statement Debacle

C++ has several places where it's legal to declare a variable in a restricted scope that's not simply a nested block. For example, it's possible to declare a variable in the condition of an if-statement. The variable will be available in the statements controlled by the condition, both the "true" and "false" branches:

if( char *theName = lookup( name ) ) { 


   // do something with name . . .


}


// theName is out of scope here

Formerly, the variable would have been declared outside the if-statement, with the unfortunate consequence that it would still be hanging around, looking for trouble, after we'd finished with it:

char *theName = lookup( name ); 


if( theName ) {


   // do something with name . . .


}


// theName is still available here . . .

It's generally a good idea to restrict the scope of a variable to the region of the program in which it's used. Under maintenance, for reasons beyond my ability to understand, these variables tend to be reused for some wildly different purpose. The effect on documentation and maintenance is, shall we say, "negative." (See also Gotcha #48.)

theName = new char[ ISBN_LEN ]; // need buffer for ISBN 

The same is true of the for-statement; an iteration variable can be declared as the first part of the statement:

for( int i = 0; i < bufSize; ++i ) { 


   if( !buffer[i] )


       break;


}


if( i == bufSize ) // was legal, now illegal, i not in scope


   // . . .

This was legal C++ for many years, but the scope of the iteration variable has changed. Formerly, the scope of the variable extended from the point of its declaration (just before the initializer; see Gotcha #21) to the end of the block that contains the for-statement. Under the new semantics, the scope is restricted to the for-statement itself. Although most C++ programmers believe that the change makes good sense in most ways—it's more orthogonal to the rest of the language, makes it easier to optimize loops, and so on—it's something of a pain in the neck to go back and repair all the older uses of for.

Sometimes it's more than just a pain in the neck. Consider the possibility of a quiet change in meaning:

int i = 0; 


void f() {


   for( int i = 0; i <bufSize; i++ ) {


       if( !buffer[i] )


       break;


   }


   if( i == bufSize ) // file scope i!


       // . . .


}

Fortunately, this kind of error is rare, and most quality compilers will warn about the condition. Take the warning seriously (and don't turn off warnings), and try to avoid hiding outer scope names in inner scopes. And lay off the global variables. (See Gotcha #3.)

Strangely, the most damaging effect of the scope change in the for-statement has been its effect on how some C++ programmers write their for-statements:

int i; 


for( i = 0; i < bufSize; ++i ) {


   if( isprint( buffer[i] ) )


       massage( buffer[i] );


   // . . .


   if( some_condition )


       continue;


   // . . .


}

This is C code, not C++ code. It does have the advantage of having the same meaning under both the old and new for-statement semantics, but consider what's been lost. First, the iteration variable remains in force after the for-statement. Second, the variable i is not initialized. Neither of these is an issue when the code is first written, but under maintenance, less experienced programmers may attempt to use the uninitialized i before the for-statement as well as after, when the original designer had hoped i would quietly disappear.

Another problem is that the issue drives some programmers away from the for-statement entirely:

int i = 0; 


while(  i < bufSize ) {


   if( isprint( buffer[i] ) )


       massage( buffer[i] );


   // . . .


   if( some_condition )


       continue; // oops!


   // . . .


   ++i;


}

The problem here is that the while-statement is not equivalent to the for-statement. For example, if there's a continue within the body of the loop, the program will suffer a change in meaning that may not be easily detected. In this case the code will infinite loop, which is usually an indication of some sort of problem. We aren't always so lucky.

If you're fortunate enough to deal exclusively with platforms that support the new for-statement semantics, the best procedure for dealing with the change in meaning of the for-statement is to embrace the change as soon as your platforms allow.

Unfortunately, it's perhaps more often the case that code must be compiled on different platforms, with contradictory for-statement semantics. It may seem logical in this case to write for-statements that have the same meaning under either translation:

int i; 


for( i = 0; i < bufSize; ++i ) {


   if( isprint( buffer[i] ) )


       massage( buffer[i] );


   // . . .


}

However, I recommend instead that all for-statements be written to the new semantics. To avoid problems with the scope of the iteration variable, the for-statement can be enclosed in a block:

{for( int i = 0; i < bufSize; ++i ) { 


   if( isprint( buffer[i] ) )


       massage( buffer[i] );


   // . . .


}}

This is hideous enough that it will surely be noticed and removed when no longer needed. It also has the advantage of encouraging the original programmer to write the for-statement to the new semantics, avoiding the need to perform that bit of additional maintenance later.