Comparisons produce bools
Lesson 2-1 showed how bool values reach the output stream, and the same rule applies to comparisons. The statement std::cout << (5 > 3); prints 1, because 5 > 3 evaluates to the bool value true and bools print as 1 or 0 unless std::boolalpha has been switched on.
That fact is the foundation of this unit. A comparison is not special syntax that only if understands, it is an ordinary expression producing an ordinary bool, which is why a condition can be stored in a variable, returned from a function, or printed.
Control flow is where a program stops being a calculator and starts making decisions. Input validation, game logic, and the edge-case handling that separates an accepted DSA solution from a rejected one are all ifs and loops arranged carefully. C++'s versions look almost identical to Python's, so this unit is mostly about the few traps where they differ.
if / else if / else
Same idea as Python, different clothing: the condition goes in parentheses, the body goes in braces, and there is no elif, just else if.
int score = 87; if (score >= 90) { std::cout << "A\n"; } else if (score >= 80) { std::cout << "B\n"; } else { std::cout << "C or below\n"; }
Comparisons: == != < <= > >=. Logic: && is Python's and, || is or, ! is not.
Two classic traps:
=assigns,==compares.if (x = 5)assigns 5 to x and is always true. Most compilers warn, always read the warning.- Braces are optional for a single statement, but skipping them causes real bugs when a second line is added later. Always write the braces.
Classifying a temperature into three bands
An if / else if / else chain over a value read from input. Only one of the three branches ever runs.
#include <iostream> int main() { int temp; std::cin >> temp; if (temp >= 30) { std::cout << "hot\n"; } else if (temp >= 15) { std::cout << "mild\n"; } else { std::cout << "cold\n"; } return 0; }
Input
31Output
hot
With 31 on the input, the first condition succeeds and the rest of the chain is skipped entirely. The else if is never even evaluated, which is worth knowing when a condition is expensive to compute.
The chain is ordered from the highest band downward, and that ordering is what lets each test be a bare >= with no upper bound. By the time temp >= 15 is reached, the value is already known to be below 30, so no temp < 30 clause is needed. Written in the opposite order, an input of 31 would match temp >= 15 first and be reported as mild.
Assignment inside a condition
The bug in if (lives = 0) { std::cout << "game over"; } is a single missing =. The line assigns 0 to lives rather than comparing against it, so game over never prints and the player's remaining lives are destroyed in the process.
The mechanics are worth spelling out. lives = 0 is an expression whose value is the value assigned, namely 0, and a condition of 0 counts as false. So the body never runs, and the damage to lives happens silently on every pass through that line. The correct comparison is lives == 0.
This bug compiles and runs cleanly, which makes it nastier than any syntax error. Compilers do warn about it, usually with a message about suggesting parentheses around an assignment used as a truth value, so this is a strong argument for building with warnings enabled and reading them.
A defensive habit some C++ programmers adopt is to write the constant first, as
if (0 == lives). If the=is then mistyped,0 = livesis not a valid assignment target and the compiler rejects it outright.
Classifying a number as even or odd
The remainder operator from lesson 2-2 answers this in one comparison, since n % 2 is 0 exactly when n divides evenly by 2.
#include <iostream> int main() { int n; std::cin >> n; if (n % 2 == 0) { std::cout << "even\n"; } else { std::cout << "odd\n"; } return 0; }
Input
42Output
even
The condition reads n % 2 == 0, and both operators matter. % computes the remainder and == compares it, so leaving out the comparison and writing if (n % 2) would invert the logic, since a remainder of 1 counts as true.
For negative inputs, C++ gives -3 % 2 as -1 rather than 1, so a test written as n % 2 == 1 would report -3 as even. Comparing against 0, as this code does, is correct for negatives as well as positives, which is why it is the idiom to prefer.