P171, continue statement. Broken model?

jstrudwick · June 5th, 2009, 02:41 PM

I understand the meaning and usage of your examples on pages 171 and 172 in reference to the continue statement.

Code:

for (ID = 0; true; ID++)
{
   state = readSensor(ID);

   if (state == true)
   {
      soundAlarm();
      callFireDepartment();
      continue;
   }

   if (ID == MAXSENSORS)
   {
      ID = -1; // -1 so increment operator sets it to 0
   }
}

I'm wondering if the continue statement in these examples don't actually break the functioning of the code in a situation where the sensor that is tripped (true) is equal to MAXSENSORS? Wouldn't that allow ID to become a value greater than MAXSENSORS and thus ID will never get set to -1 until the routine is restarted?

In essence is there really a need for the continue statement in this code for anything other than an example of it's usage?

DrPurdum · June 6th, 2009, 09:41 PM

You're right. Actually, I think the technical editor on the book also caught this error (I was tempted to say I caught it, but..alas...I didn't). I'm not sure how it slipped through to production. The proper way to fix it is to place a statement just above the continue statement that resets the value of ID.

While the code is clearly wrong, eventually the code would reset itself. That's the good news. The bad news is that it would have to cycle through several billion interations of the loop before it was reset!

Sorry for the error...

comecme · November 30th, 2010, 08:45 AM

I actually don't get the point of the continue statement in this example. Especially if you want to fix the problem mentioned by jstrudwick, wouldn't it be much simpler to just leave out the continue statement at all?

I suppose the problem is that it's hard to come up with a good example where the continue statement actually makes sense. Allmost all samples I found have code that skips some values, something like

Code:

for (int i = 1; i <= 10; i++)
{
   if (i == 4)
   {
     continue;
   }
   Console.WriteLine(i);
}

That could easily be rewritten to

Code:

for (int i = 1; i <= 10; i++)
{
   if (i != 4)
   {
     Console.WriteLine(i);
   }
}

Off course there is one difference, the indentation of the Console.WriteLine(i); So maybe, the statement is usefull for preventing deep nesting? Or is it more something that's up to the programmer. Some might find it makes more sense to explicitely state that you want to continue with the next iteration and skip the rest of the loop.

DrPurdum · November 30th, 2010, 03:32 PM

Almost any example I can think of for the continue statement can be rewritten without it, which probably explains why you rarely see it used in "real" code. Indeed, I have a sneaky suspicion that the compiler often reorganizes the code so it behaves like it's not there anyway. Perhaps one argument for the continue statement is that it can document the intent of the code in a manner that might be more clear in some cases. If it is true that the compiler optimizes the (more verbose) code using the continue away but the code remains better documented, perhaps the continue should be used.

If anyone has a really good example of the continue statement, I'd like to see it.