10. The For Loop

Advanced perspective: counted iteration and invariants

A for loop describes a controlled sequence of states

A loop that prints the expected answer once may still contain the wrong bound, the wrong update or an accidental dependence on the data used for that run. The operative test is whether its initial state, continuation condition, body and update jointly describe the required sequence. Each part has a job. If you cannot account for the state at the boundary between two iterations, the final answer is weaker evidence than it appears.

The three expressions in a conventional for header gather the control policy into one visible place. That is why the form is useful for counted work. The syntax itself does not promise a known number of iterations, or even termination. Those properties must follow from the actual values and transitions.

Execution order is the first thing to get right

The order is therefore: initialise, test, execute the body, update, test again. The initialisation does not repeat. The update does not happen before the first body. When the condition is false, the body and update are skipped and execution continues after the loop. A continue statement inside a for loop also leads to the update before the next condition test; it does not jump directly to the condition.

When the control variable is declared in the initialisation, it is available to the condition, the body and the update. It is not available after the for statement has finished. That scope is useful evidence: the name exists for the policy it controls, then disappears.

Trace control state and useful state separately

#include <iostream>

int main() {
    int sum{0};

    for (int value{2}; value <= 10; value += 2) {
        sum += value;
    }

    std::cout << "Sum: " << sum << '\n';
}

Here, value controls the sequence and sum records the work already completed. Confusing those roles is dangerous. The loop must advance value even though the calculation of interest is stored in sum.

The output is Sum: 30 followed by a newline. More importantly, the trace explains why. Before each condition test, sum is the total of the required even values that are less than value. This statement is the loop invariant.

It is true initially: no required value is less than 2, and the sum is zero. If it is true when the condition admits the current value, the body adds that value and the update moves to the next even candidate, so the statement is true again. At exit, value is 12 and the condition is false. The invariant then tells us that all required even values through 10 have been included. Initial truth, preservation and a useful exit condition turn the trace into a correctness argument.

A bound is correct only in relation to the intended range

The use of <= in this program is deliberate because 10 belongs to the required arithmetic range. Replacing it with < would omit 10 and produce 20. This is not an argument that inclusive bounds are generally safer. It shows that a comparison has no meaning in isolation from the range it represents.

Indices usually describe a different range. If a sequence contains count elements, its valid indices are normally zero through count - 1. The half-open form 0 <= index && index < count states that contract directly. It also handles an empty sequence: when count is zero, the first test fails and the body does not run.

This is why counting the number of body executions is only one check. A loop can execute five times and still visit the wrong five values. The actual sequence is the evidence.

Separate the invariant, progress and exit claim

Three questions expose most defects in a counted loop. What must be true whenever the condition is tested? Which state change moves the loop towards termination? What does the false condition establish when the loop exits? An invariant without progress can describe an endless loop. Progress without the right invariant can terminate after doing the wrong work. A false condition that says nothing useful about completed work cannot justify the result on its own.

Modifying the control variable inside the body deserves special suspicion because it creates a second update policy away from the header. It is not forbidden by C++, and there are specialised loops where it is intentional. However, if the body reads user input into the control variable, the next candidate and the termination argument now depend on arbitrary input. A separate input variable keeps the counted policy inspectable.

A range-based for loop is often clearer when the requirement is simply to process every element and the position has no separate meaning. A conventional counted loop remains appropriate when the index is part of the result, a subrange is required or the step itself matters. Choose the form that makes the required state visible. Familiar syntax is not the criterion.

Performance follows correctness, not the other way round

Iteration order can affect performance because data representation and access pattern influence locality. That claim does not rescue an unsafe bound, and it does not prove that a short benchmark predicts the complete application. Establish the visited range and state transitions first. If performance is material, measure the real workload and interpret the result in the context of its data size, layout, compiler settings and machine.

Prove a small change before you run it

Change the upper endpoint of the worked requirement from 10 to 14. Before editing the condition, predict every admitted value, every value of sum after the body and the first failed condition test.

Then test a half-open index loop with sequence lengths zero, one and five. For each length, write the candidate indices before running the program. If the body executes for an index equal to the length, the boundary is wrong. Stop at the first failed test, inspect the state and explain the exit claim. That discipline scales beyond this example because it tests the loop's argument, not your confidence in its appearance.

int sum{0};

for (int value{2}; value <= 14; value += 2) {
    sum += value;
}

for (std::size_t index{0}; index < length; ++index) {
    // Use the element at index.
}