In languages that have switch
, usually a break;
statement is needed. What if a switch
within a switch
statement? Is it necessary to put a break;
statement in the outer switch
when the inner switch
has a break;
? e.g.:
// outer switch
switch (a) {
case 1:
// inner switch
switch (b) { // this inner switch breaks either way.
case (2):
break;
default:
break;
}
break; // is this outer break still necessary?
default:
break;
}
I hope someone can help me to understand the logic more deeply and accurately.
CodePudding user response:
// is this outter break still neccessary?
Yes.
Alternatively you could show the nested switch
inside a function and return
instead of break
. Likely far more readable.
CodePudding user response:
Both break
statements are useful. This gives the language greater flexibility, and it keeps the language itself simpler to work with.
You seem to be thinking of a simple situation, where the nested switch
is choosing which one thing to do. This is often a good design. However, what if more needs to be done? There might be more work to do after breaking out of the inner switch.
// outer switch
switch (a) {
case 1:
// inner switch
switch (b) {
case 2:
std::cout << "The b value is acceptable.\n";
break;
default:
std::cout << "The inner default.\n";
break;
}
std::cout << "The first case has finished.\n";
break;
default:
break;
}
If the inner break
jumped out of the outer switch
in this example, you would never see the output The first case has finished.
Limiting the impact of a break
allows for more complex code flow. (Not that complex code is desirable, but it's nice to have options.)
On top of that, if your code is not kept simple, it could quickly become difficult to deduce what the impact of a break
statement is. You mentioned switch
statements, but break
statements also affect loops. If a switch
is inside a loop, should a break
in the switch
also break out of the loop? What if the loop was itself inside a switch
(that is, if you nest the statements switch
- while
- switch
)? What would you expect a break
in the inner switch
to do? Exiting everything is unlikely to be desired. Besides, there is already a language feature that allows breaking out of multiple nesting levels (known as return
).
There is a design principle that says to keep it simple. If your code is simple, you won't have these monster situations to worry about. At the same time, the principle also applies to language design. If the syntax rules for the language are kept simple (a break
statement consistently breaks out of a single statement), then life is easier for the people using the language.