The first category of control flow statements we’ll talk about are the conditional statements. A conditional statement is a statement that specifies whether some associated statement(s) should be executed or not.
C++ supports two basic kind of conditionals: if statements
(which we introduced in lesson 4.10 -- Introduction to if statements, and will talk about further here) and switch statements
(which we’ll cover in a couple of lessons).
Quick if-statement recap
The most basic kind of conditional statement in C++ is the if statement
. An if statement
takes the form:
if (condition) true_statement;
or with an optional else statement
:
if (condition) true_statement; else false_statement;
If the condition
evaluates to true
, the true_statement
executes. If the condition
evaluates to false
and the optional else statement
exists, the false_statement
executes.
Here is a simple program that uses an if statement
with the optional else statement
:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
#include <iostream> int main() { std::cout << "Enter a number: "; int x{}; std::cin >> x; if (x > 10) std::cout << x << "is greater than 10\n"; else std::cout << x << "is not greater than 10\n"; return 0; } |
This program works just like you’d expect:
Enter a number: 15 15 is greater than 10
Enter a number: 4 4 is not greater than 10
If or else with multiple conditional statements
New programmers often try something like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
#include <iostream> int main() { std::cout << "Enter your height (in cm): "; int x{}; std::cin >> x; if (x > 140) std::cout << "You are tall enough to ride.\n"; else std::cout << "You are not tall enough to ride.\n"; std::cout << "Too bad!\n"; // focus on this line return 0; } |
However, consider the following run of the program:
Enter your height (in cm): 180 You are tall enough to ride. Too bad!
This program doesn’t work as expected because the true_statement
and false_statement
can only be a single statement. The indentation is deceiving us here -- the above program executes as if it had been written as follows:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
#include <iostream> int main() { std::cout << "Enter your height (in cm): "; int x{}; std::cin >> x; if (x > 140) std::cout << "You are tall enough to ride.\n"; else std::cout << "You are not tall enough to ride.\n"; std::cout << "Too bad!\n"; // focus on this line return 0; } |
This makes it clearer that “Too bad!” will always execute.
However, it’s common to want to execute multiple statements based on some condition. To do so, we can use a compound statement (block):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
#include <iostream> int main() { std::cout << "Enter your height (in cm): "; int x{}; std::cin >> x; if (x > 140) std::cout << "You are tall enough to ride.\n"; else { // note addition of block here std::cout << "You are not tall enough to ride.\n"; std::cout << "Too bad!\n"; } return 0; } |
Remember that blocks are treated as a single statement, so this now works as expected:
Enter your height (in cm): 180 You are tall enough to ride.
Enter your height (in cm): 130 You are not tall enough to ride. Too bad!
To block or not to block single statements
There is debate within the programmer community as to whether single statements following an if
or else
should be explicitly enclosed in blocks or not.
There are two reasons typically given as rationale for doing so. First, consider the following snippet:
1 2 |
if (age >= 21) purchaseBeer(); |
Now let’s say we’re in a hurry and modify this program to add another ability:
1 2 3 |
if (age >= 21) purchaseBeer(); gamble(); // will always execute |
Oops, we’ve just allowed minors to gamble. Have fun in jail!
Second, it can make programs more difficult to debug. Let’s say we have the following snippet:
1 2 3 4 |
if (age >= 21) addBeerToCart(); checkout(); |
Let’s say we suspect something is wrong with the addBeerToCart()
function, so we comment it out:
1 2 3 4 |
if (age >= 21) // addBeerToCart(); checkout(); |
Now we’ve made checkout()
conditional, which we certainly didn’t intend.
Neither of these problems occur if you always use blocks after an if
or else
statement.
The best argument for not using blocks around single statements is that adding blocks makes you able to see less of your code at one time by spacing it out vertically, which makes your code less readable and can lead to other, more serious mistakes.
The community seems to be more in favor of always using blocks than not, though this recommendation certainly isn’t ubiquitous.
Best practice
Consider putting single statements associated with an if
or else
in blocks.
A middle-ground alternative is to put single-lines on the same line as the if
or else
:
1 |
if (age >= 21) purchaseBeer(); |
This avoids both of the above downsides mentioned above at some minor cost to readability.
Implicit blocks
If the programmer does not declare a block in the statement portion of an if statement
or else statement
, the compiler will implicitly declare one. Thus:
if (condition) true_statement; else false_statement;
is actually the equivalent of:
if (condition) { true_statement; } else { false_statement; }
Most of the time, this doesn’t matter. However, new programmers sometimes try to do something like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
#include <iostream> int main() { if (true) int x{ 5 }; else int x{ 6 }; std::cout << x; return 0; } |
This won’t compile, with the compiler generating an error that identifier x
isn’t defined. This is because the above example is the equivalent of:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
#include <iostream> int main() { if (true) { int x{ 5 }; } // x destroyed here else { int x{ 6 }; } // x destroyed here std::cout << x; // x isn't in scope here return 0; } |
In this context, it’s clearer that variable x
has block scope and is destroyed at the end of the block. By the time we get to the std::cout
line, x
doesn’t exist.
We’ll continue our exploration of if statements
in the next lesson.
![]() |
![]() |
![]() |
Great lesson! I look forward to the rest of this chapter.
1. Section "Quick if-statement recap":
> This program works just like you’d expect:
5 should be 4 (or vice versa)
2.
> Now we’ve made checkout() conditional, which we certainly didn’t intend.
Oh, wow. I've always thought that if-statements execute the next line, not the next statement. I forgot C++ ignores whitespace.
Fixed! (Also fixed the other lessons based on your feedback). Thank you!
In the previous chapter S4.5-Enumerated Types
"Best practice
Don’t assign specific values to your enumerators."
It's confusing.
Which rule do we follow?
Like pretty much all programming. It depends. As a general rule you shouldnt assign specific values, but there are some cases where it makes sense. When in doubt follow generalized rules unless you have a good reason not to.
Using an enum class in this case makes sense, it keeps things together all in one place, but an equally valid solution would have been to store them as constants in a namespace. This is just less work and serves the purpose of the example well.
Chosing to store it as an enum instead of a constant means that it can be passed as a variable instead of just an int value, which can be really helpful sometimes. You inherently get more information with an enum variable than you do with just an int.
No specific values should have been assigned in this example, I've updated the lesson. Thanks for pointing it out!
What you quoted is a "Best practice", and that's also what @TigerTM described. Follow the "Best practice" unless you have a good reason not to. For specific enumerator values, a good reason to diverge from the best practice can be that the values must not change during updates or that the values are exposed to the user. Both these scenarios can be met with error code enums. If error code 42 meant "file not found" in program version 1.2.1, it should still have the same meaning in version 1.3.4. By assigning specific values, you're preventing the programmer from inserting an enumerator between others, thus shifting all values.
Since the enumerator values aren't exposed in this example, there's no need for specific values to be used.
Hi Alex and Tiger,
Thank you for clarifying.
it allows multiple init statements of same type but not different types or am i missing a point here
Correct. The init-statement ends at the semicolon.
Shouldn't the first line of the "Using logical operators with if statements" chapter end with "(covered in section 5.7 -- Logical operators)" instead of "(covered in section 3.6 -- logical operators)"?
Yep, thanks!