11. The While (and Do) Loops

Advanced perspective: progress and termination

A while loop is governed by state, not unpredictability

Not knowing the iteration count in advance does not make a loop random. If a file contains an unknown number of integers, the program cannot write the count into its source, but the next input operation can still decide the path precisely. Run the same program with the same starting state and input, and you should expect the same decisions. The count was unknown before execution. The controlling evidence was not.

The real criterion is whether the loop exposes the state that permits one more iteration and the event that changes that state. A familiar while header is not enough. If the condition observes a fact that the body never changes, or an input operation fails without the failure being handled, the program can repeat a stale state indefinitely.

Test placement changes the minimum amount of work

A condition is evaluated at those test points; it is not monitored continuously while the body runs. In a while loop, a state change halfway through the body does not interrupt that body automatically. Control reaches the next test only through the program's stated control flow. In a do-while, remember that the final condition is followed by a semicolon because it completes the statement.

A menu illustrates the post-test case only when showing the menu once is genuinely required before deciding whether to show it again. Input processing often belongs in a pre-test loop because the body must not use a value until the read has succeeded. Choosing between the forms is therefore a decision about evidence before work, not a preference for one spelling.

Let the operation that obtains a value govern its use

#include <iostream>

int main() {
    int total{0};
    int value{0};

    while (std::cin >> value) {
        total += value;
    }

    std::cout << "Total: " << total << '\n';
}

The extraction expression does two connected jobs. It attempts to read and convert the next integer into value, and it produces a stream state that can be tested as a condition. When extraction succeeds, the condition admits the body and that newly obtained value is added. When extraction cannot produce the next integer, the stream tests false and the body is not entered.

The attempt matters. End-of-file state is normally discovered by trying to read beyond the available input, not by predicting before the last valid item that it is the last. That is why while (!input.eof()) asks the wrong question. It can admit the body before the read that discovers the end has succeeded, leaving the program tempted to process a value that was not obtained by that iteration.

Putting the extraction in the condition ties permission to use value to evidence that this extraction succeeded. The same reasoning applies to std::getline(input, line). It is not a magic idiom to memorise. It is a boundary: acquire a new item and enter the body only if acquisition succeeded.

Stopping on failure is not the same as handling failure

The compact program stops when no further integer can be extracted. End of input, text where an integer was required and a more serious stream failure can all lead out of the loop, but they do not necessarily deserve the same program response. If the requirement says that a completed file is normal but malformed input must be reported, the stream state must be examined after the loop and the cases distinguished.

Recovery is a separate policy. For malformed interactive input, the program may clear the failure state and deliberately discard or otherwise deal with the offending characters before trying again. Clearing the flags alone is not progress. If the same unacceptable characters remain available for the next extraction, the next attempt fails for the same reason and the loop has acquired a very efficient way to do nothing.

A sentinel adds another deliberate exit. In while (std::cin >> value && value != 0), short-circuit evaluation first requires a successful extraction. Only then is the value compared with zero. The sentinel is read, but it is not processed by the body. Failed input is not compared as though it were a new value. Those are distinct exit events, even if both leave the loop.

Progress must be stated in the terms of the problem

For a search with a finite set of unexamined elements, the number remaining can provide a loop variant: after an unsuccessful step, that number must fall. For a countdown, the control value approaches its bound. For an input loop, a successful iteration consumes an item, while exhaustion or failure prevents another body execution. For a menu, a recognised quit event changes the state that controls continuation.

Not every interactive or external loop can be proved to terminate independently of its environment. A service may be intended to wait for work until it is told to stop. An input loop may wait because a person never supplies a value or end signal. The honest claim is then conditional: when one of the specified exit events occurs, the loop detects it and follows the required path. Do not disguise an environmental assumption as a mathematical guarantee.

A safety boundary contains damage; it does not repair logic

An iteration limit, deadline or watchdog can be valuable when the requirement imposes a real work or time budget. It can also leave a diagnostic instead of allowing an unintended loop to consume resources without bound. However, reaching that boundary proves only that the safety mechanism acted. It does not prove the underlying algorithm made progress or completed its task.

A bare break has the same limitation. It changes control flow, but it does not make the original condition correct. Each break should correspond to an explainable event, and the code after the loop must know whether work completed, a sentinel was received, an error occurred or a safety budget was exhausted.

Trace failure before designing recovery

Use the input sequence 4 7 -2 x 9 with the worked program. Predict each attempted extraction and the total before running it.

Now decide what the requirement should do with x. Stop and report malformed input? Discard the rest of its line and ask again? Treat a specific token as a sentinel? Write the policy first, then identify the exact stream-state and character-handling operations needed to make the next attempt different from the failed one. Finally, test empty input and input beginning with x. If the first body execution is not justified by a successful read, the loop form is wrong before recovery even begins.

#include <iostream>
#include <limits>

int main() {
    int total{0};
    int value{0};

    for (;;) {
        if (std::cin >> value) {
            total += value;
            continue;
        }

        if (std::cin.bad()) {
            std::cerr << "Input error\n";
            return 1;
        }
        if (std::cin.eof()) {
            break;
        }

        std::cerr << "Expected an integer; discarding this line\n";
        std::cin.clear();
        std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n');
    }

    std::cout << "Total: " << total << '\n';
}