Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

cybrscot

macrumors 6502
Original poster
Dec 7, 2010
282
0
Somewhere in Southeast Asia
Books Question:
11. Which one of the following statements is not equivalent to the other two (assuming that the loop bodies are the same).

a) while ( i < 10 ) {...}
b) for (; i < 10 ; ) {...}
c) do {...} while ( i < 10 ) ;

I think the answer is "c". because both a and b place a condition before running the loop, and c runs the loop first, then checks the conditional. Correct?
 
Books Question:
11. Which one of the following statements is not equivalent to the other two (assuming that the loop bodies are the same).

a) while ( i < 10 ) {...}
b) for (; i < 10 ; ) {...}
c) do {...} while ( i < 10 ) ;

I think the answer is "c". because both a and b place a condition before running the loop, and c runs the loop first, then checks the conditional. Correct?

Not wrong, but it doesn't answer the question. Describe exactly in which situation which statement will behave differently from the others and why.
 
Not wrong, but it doesn't answer the question. Describe exactly in which situation which statement will behave differently from the others and why.

Gee, I'm not sure at this point how to give you a "real world" example if that's what you mean... I know that the loops "can" produce the same result. But I also know by definition that a and b will test a "condition" before the loop is run, running the loop only if the condition is true. And C will run the loop automatically first, then will decide whether to run it subsequent times after the condition. So it's possible to have a situation in which I must choose the "right" loop because their output will be quite different.

I'm not sure what kind of example you mean, it's difficult for me to come up with a program, that will run differently on each loop as I don't have much practical experience writing my own programs yet. I've only written 2 of my own, and they were both programs exploiting the use of the switch statement.

Can you be more clear on what I'm supposed to be doing to satisfy your qualification? Or is the above sufficient?


EDIT: Maybe I can just tell you that if I have a program in which a condition MUST be met before executing the loop, then a and b are both available. Like running the loop only if userNumber is less/greater/equal to/than a pre-determined number. Whereas if I want the loop to run first, and later stop based on meeting a certain condition.
 
The critical difference between a, b and c is that in (c) the loop body will always be executed at least once, while in (a) and (b) the loop body is not executed at all if the first test fails. If for example i == 10 before the start of your example, the loop body will be executed.

For the second and later iterations it doesn't matter whether the test is done before or after the loop body, because either way there is a test before the second iteration, before the third iteration and so on. But the do { ... } while ... loop doesn't perform a test before the first iteration.
 
Not wrong, but it doesn't answer the question. Describe exactly in which situation which statement will behave differently from the others and why.

You're being more strict than the question itself. I think he does answer the question, even explaining his rationale.
 
Gee, I'm not sure at this point how to give you a "real world" example if that's what you mean... I know that the loops "can" produce the same result. But I also know by definition that a and b will test a "condition" before the loop is run, running the loop only if the condition is true. And C will run the loop automatically first, then will decide whether to run it subsequent times after the condition. So it's possible to have a situation in which I must choose the "right" loop because their output will be quite different.

This is absolutely correct. You are right and you have explained it well.

As for real world examples: here's a very simple one. Suppose you have a program to collect a bunch of input from the user. You could write it in two ways. Pseudocode below:

Approach 1:

print "How many entries do you want to input?"
input count

for (i = 0; i < count; i++)
{
print "input the next value:"
input value
}

Approach 2:
do
{
print: "Enter the next value, or -1 if you are done:"
input value
} while (value != -1)
 
Last edited:
I think I would use a while-loop instead of a do-while loop. But if you do that, you'll need to read your first piece of input outside that loop.
 
Depends on the flow of your program and what you're entering. I never was a fan of do-whiles until I started programing in C/C++/C#.

For someone in the audience who doesn't quite know what we're talking about, this is a trivial example but I've seen more complex examples from newbies that are just plain ugly code:

Code:
std::string someVal;

std::cout << "Try and crash me: ";
std::cin >> someVal;

while(!makeSureImANumber(someVal)){

std::cout << "Try and crash me: ";
std::cin >> someVal;

}

Obviously this is easier to follow, less lines, cleaner execution, and less ambiguity when errors pop up:

Code:
std::string someVal;

do{

std::cout << "Try and crash me: ";
std::cin >> someVal;

}while(!makeSureImANumber(someVal));

Also for the purposes of the question, digging deeper, a & b are not only functionally the same but should equate to the same assembly language since all loops are just jumps and comparisons.
 
Last edited:
I think I would use a while-loop instead of a do-while loop. But if you do that, you'll need to read your first piece of input outside that loop.

Is there a reason behind that? Or just personal preference/easy reading? Because, you know, while loops are complied with one more machine instruction (jump forward to the while test) than do-while loops. In practical terms, there is absolutely no good reason to choose a while loop if a do-while makes sense.
 
Is there a reason behind that? Or just personal preference/easy reading? Because, you know, while loops are complied with one more machine instruction (jump forward to the while test) than do-while loops. In practical terms, there is absolutely no good reason to choose a while loop if a do-while makes sense.
If the loop condition is already false when control flows to the while-loop, the machine won't execute that loop's body then. Maybe a do-while saves a machine instruction. But the do-while's body may be a huge, slow chunk of code that you'll need to execute before you test the loop condition. Compared to a loop body's long execution time, the forward-jump's execution time probably will be trivial.

Yes, I do think a while-loop is more readable than a do-while loop.
 
Last edited:
If the loop condition is already false when control flows to the while-loop, the machine won't execute that loop's body then. Maybe a do-while saves a machine instruction. But the do-while's body may be a huge, slow chunk of code that you'll need to execute before you test the loop condition. Compared to a loop body's long execution time, the forward-jump's execution time probably will be trivial.

Yes, I do think a while-loop is more readable than a do-while loop.

Much or most of the time I find the while-loop the appropriate tool. But there are times when you know you will want at least one pass (e.g., inside an if -lock where the initial condition has already been established), in which case, one should use do-while, because rigging up a while-loop to serve your need would be pointless. You should always use the appropriate tool.
 
Much or most of the time I find the while-loop the appropriate tool. But there are times when you know you will want at least one pass (e.g., inside an if -lock where the initial condition has already been established), in which case, one should use do-while, because rigging up a while-loop to serve your need would be pointless. You should always use the appropriate tool.
Agreed. Sometimes, when I program in Pascal, I use a repeat-until loop for the reasons Sydde gave just now. Other times, I use it because I prefer positive loop conditions to negated ones. But that preference may be merely a preference.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.