{"title":"Switch Statement","description":null,"content":"When a program has to choose one branch out of many based on a single discrete value, an `if`/`else if` ladder gets noisy fast. A `switch` statement is C++'s purpose-built tool for that pattern: one expression, many possible values, one matching branch. This lesson covers the syntax, the types `switch` accepts (and the ones it refuses), the famous fallthrough trap, the `[[fallthrough]]` attribute, declaring variables inside cases, the C++17 initializer form, and how to decide between `switch` and `if`/`else`.\n\n---\n\n# The Basic Shape\n\nA `switch` takes one expression in parentheses and compares its value against a list of `case` labels. The matching label is the entry point. Execution then runs forward through the body until it hits a `break` (or falls off the end of the switch).\n\n\n```cpp\n#include \n\nint main() {\n int orderStatusCode{2};\n\n switch (orderStatusCode) {\n case 1:\n std::cout << \"Order placed\" << std::endl;\n break;\n case 2:\n std::cout << \"Order shipped\" << std::endl;\n break;\n case 3:\n std::cout << \"Order delivered\" << std::endl;\n break;\n case 4:\n std::cout << \"Order cancelled\" << std::endl;\n break;\n default:\n std::cout << \"Unknown status\" << std::endl;\n break;\n }\n return 0;\n}\n```\n\n\nThe pieces line up like this:\n\n- The expression in `switch (orderStatusCode)` is evaluated once.\n- Each `case X:` is a label. If the expression equals `X`, control jumps to that label.\n- `break` ends the switch. Without it, execution would continue into the next case.\n- `default:` is the fallback. If no case matches, that's where execution lands.\n\nA `case` label is not a separate scope on its own. It's just a marker inside one big block. That detail matters once you start declaring variables inside cases, which we'll get to.\n\n---\n\n# What Types Switch Accepts\n\n`switch` only works on values of an **integral or enumeration type**. That covers `int`, `short`, `long`, `long long`, `char`, `bool`, plain `enum`, and `enum class`. It does not work on `std::string`, `double`, `float`, or any user-defined class.\n\nThe reason comes from how `switch` is implemented. The compiler is allowed (and often does) translate a `switch` into a jump table: an array of code addresses indexed by the case value. That only works when the labels are compile-time integer constants and the input is an integer that can be hashed or indexed directly. Floating-point values can't be compared for equality safely (rounding errors make `0.1 + 0.2 != 0.3`), and strings need character-by-character comparison, which is the opposite of a single integer jump. So C++ refuses both at the language level.\n\n### Plain Integers and `char`\n\n`char` is just a small integer, so it slots in cleanly. This is handy for menu-style code where the user types a single letter.\n\n\n```cpp\n#include \n\nint main() {\n char menuChoice{'s'};\n\n switch (menuChoice) {\n case 'p':\n std::cout << \"Browse products\" << std::endl;\n break;\n case 's':\n std::cout << \"Search catalog\" << std::endl;\n break;\n case 'c':\n std::cout << \"View cart\" << std::endl;\n break;\n case 'q':\n std::cout << \"Quit\" << std::endl;\n break;\n default:\n std::cout << \"Unknown choice\" << std::endl;\n break;\n }\n return 0;\n}\n```\n\n\nEach `case` label is a `char` literal, which is really a small integer constant. The compiler is happy.\n\n### `enum` and `enum class`\n\nSwitching on enums is one of the cleanest uses of `switch`. The cases name themselves, and the compiler can warn you if you forget one.\n\n\n```cpp\n#include \n\nenum class OrderStatus {\n PLACED,\n SHIPPED,\n DELIVERED,\n CANCELLED\n};\n\nint main() {\n OrderStatus status{OrderStatus::SHIPPED};\n\n switch (status) {\n case OrderStatus::PLACED:\n std::cout << \"Order placed, waiting for warehouse\" << std::endl;\n break;\n case OrderStatus::SHIPPED:\n std::cout << \"On the way\" << std::endl;\n break;\n case OrderStatus::DELIVERED:\n std::cout << \"Delivered\" << std::endl;\n break;\n case OrderStatus::CANCELLED:\n std::cout << \"Cancelled, refund issued\" << std::endl;\n break;\n }\n return 0;\n}\n```\n\n\nAn `enum class` value can't be compared to a plain `int` without a cast, and that strictness extends to `switch`. The case labels must be `OrderStatus::PLACED` and friends, not `0`, `1`, `2`, `3`. If you actually need the underlying integer (to print it, log it, or send it across a wire), you have to cast back explicitly with `static_cast`:\n\n\n```cpp\nint statusCode = static_cast(status);\n```\n\n\n\n> **INFO**\n>\n> **Tip:** When you `switch` on an `enum class` and cover every enumerator without a `default`, most compilers (g++, clang++) warn you if you later add a new enumerator and forget to handle it. That's one of the strongest reasons to switch on enums.\n\n\n### What `switch` Refuses\n\nThe following will not compile.\n\n**Floats:**\n\n\n```cpp\ndouble price{19.99};\nswitch (price) { // error: switch quantity not an integer\n case 19.99:\n // ...\n}\n```\n\n\n`switch` is built around exact integer equality. Floating-point numbers are stored as binary approximations of decimal values, so two `double`s that \"should\" be equal often aren't. The language sidesteps that whole problem by rejecting float switches outright. Use `if`/`else if` with a tolerance check (`std::abs(a - b) < 1e-9`) instead.\n\n**Strings:**\n\n\n```cpp\n#include \n\nstd::string productCategory{\"electronics\"};\nswitch (productCategory) { // error: switch quantity not an integer\n case \"electronics\":\n // ...\n}\n```\n\n\nA `std::string` is a class with member functions, not an integer. There's no way to build a jump table from one. If you want to dispatch on string values, you have an `if`/`else if` chain, a `std::unordered_map>`, or you map the strings to an enum first and switch on that.\n\n---\n\n# The Fallthrough Trap\n\nEvery case label is just a jump target. After landing on a label, execution runs forward through whatever statements come next, even crossing into the next case label, until it hits a `break` or the closing brace of the switch.\n\nThat behavior is called **fallthrough**, and forgetting a `break` is one of the most famous bug patterns in all of C and C++.\n\n**What's wrong with this code?**\n\n\n```cpp\n#include \n\nint main() {\n int orderStatusCode{1};\n\n switch (orderStatusCode) {\n case 1:\n std::cout << \"Order placed\" << std::endl;\n // forgot break\n case 2:\n std::cout << \"Order shipped\" << std::endl;\n break;\n case 3:\n std::cout << \"Order delivered\" << std::endl;\n break;\n default:\n std::cout << \"Unknown status\" << std::endl;\n break;\n }\n return 0;\n}\n```\n\n\nExecution lands on `case 1:`, prints `Order placed`, and then keeps running. There's no `break`, so it falls through into `case 2:`, prints `Order shipped`, and only stops there because that case ends with a `break`. The caller asked about a placed order and got told the order was also shipped. In a payment, shipping, or status-update system, that kind of bug can have real consequences.\n\nThe fix is mechanical: put a `break` at the end of every case unless you genuinely want fallthrough.\n\n\n```cpp\ncase 1:\n std::cout << \"Order placed\" << std::endl;\n break; // do not let execution fall into case 2\ncase 2:\n // ...\n```\n\n\n\n> **INFO**\n>\n> **Tip:** Compilers can help. `g++ -Wall -Wextra` (and `clang++ -Wall -Wextra`) enable `-Wimplicit-fallthrough`, which warns on any case that flows into the next without a `break` or an explicit fallthrough marker. Turn it on, leave it on.\n\n\n---\n\n# Intentional Fallthrough and `[[fallthrough]]`\n\nSometimes you actually want two cases to share the same body. The classic example is mapping a customer tier to a discount where the higher tiers also get everything the lower tiers get.\n\nA simple version without any explicit marker:\n\n\n```cpp\n#include \n\nint main() {\n int customerTier{2}; // 1=Bronze, 2=Silver, 3=Gold\n\n switch (customerTier) {\n case 1:\n case 2:\n case 3:\n std::cout << \"Free shipping\" << std::endl;\n break;\n default:\n std::cout << \"Standard shipping fee applies\" << std::endl;\n break;\n }\n return 0;\n}\n```\n\n\nThis is fine and idiomatic. When the case label has **no statements** between it and the next case, the compiler treats the stack of labels as a group with one shared body. No warning is produced because there's nothing to fall through past.\n\nThe trickier case is when one branch does some work and then deliberately continues into the next. That's where the `[[fallthrough]]` attribute, added in C++17, earns its place.\n\n\n```cpp\n#include \n\nint main() {\n int customerTier{3}; // 1=Bronze, 2=Silver, 3=Gold\n\n switch (customerTier) {\n case 3:\n std::cout << \"Priority support\" << std::endl;\n [[fallthrough]];\n case 2:\n std::cout << \"Free returns\" << std::endl;\n [[fallthrough]];\n case 1:\n std::cout << \"Free shipping\" << std::endl;\n break;\n default:\n std::cout << \"Standard plan\" << std::endl;\n break;\n }\n return 0;\n}\n```\n\n\nA Gold customer (tier 3) lands on `case 3:`, gets priority support, then deliberately falls through to pick up free returns and free shipping. `[[fallthrough]];` is a statement that documents intent: \"yes, the missing `break` is on purpose.\" It also tells the compiler to suppress its fallthrough warning for that one case.\n\nA few things to keep straight:\n\n- `[[fallthrough]];` is a statement and must end with a semicolon.\n- It must be the last statement in the case before control reaches the next label. You can't put it in the middle of a case body.\n- It's only meaningful right before a `case` or `default` label. Anywhere else, it's a syntax error.\n\nWithout `[[fallthrough]]`, compilers with the warning enabled flag the missing `break` as a likely bug. With it, the compiler trusts you. The reader of the code does too: the intent is right there in the source.\n\n---\n\n# The `default` Clause\n\n`default:` is the fallback label. If none of the `case` values match the switch expression, control jumps to `default:`. If there is no `default` and no case matches, the switch does nothing and execution continues after the closing brace.\n\n\n```cpp\n#include \n\nint main() {\n int productCategoryCode{99};\n\n switch (productCategoryCode) {\n case 1:\n std::cout << \"Electronics\" << std::endl;\n break;\n case 2:\n std::cout << \"Books\" << std::endl;\n break;\n case 3:\n std::cout << \"Clothing\" << std::endl;\n break;\n default:\n std::cout << \"Unknown category: \" << productCategoryCode << std::endl;\n break;\n }\n return 0;\n}\n```\n\n\nTwo practical points about `default`:\n\n- **Always include one** unless you're switching on an `enum class` and you genuinely want the compiler to warn you about missing enumerators. The `default` is your safety net for values you didn't anticipate. Without it, unexpected input slips silently past.\n- **Position is flexible, but put it last.** The language allows `default:` anywhere in the switch (even between two cases), but readers expect it at the bottom. Putting it elsewhere is needlessly confusing.\n\nThe one case where you might intentionally omit `default` is when switching over an `enum class` whose enumerators you're handling exhaustively. Tools like `-Wswitch-enum` will warn if you ever add a new enumerator without updating the switch, which is exactly the safety check you want.\n\n\n```cpp\nenum class OrderStatus { PLACED, SHIPPED, DELIVERED, CANCELLED };\n\nvoid describe(OrderStatus s) {\n switch (s) {\n case OrderStatus::PLACED: std::cout << \"Placed\\n\"; break;\n case OrderStatus::SHIPPED: std::cout << \"Shipped\\n\"; break;\n case OrderStatus::DELIVERED: std::cout << \"Delivered\\n\"; break;\n case OrderStatus::CANCELLED: std::cout << \"Cancelled\\n\"; break;\n }\n // No default. If a new enumerator is ever added to OrderStatus,\n // -Wswitch (or -Wswitch-enum) flags this function for review.\n}\n```\n\n\nThe trade-off is real: no `default` means an unmapped value (if one somehow appears, say from a cast) falls off the bottom of the switch silently. Most teams hedge by adding `default: assert(false);` or by throwing an exception, so they get both the compile-time warning and a runtime safety net.\n\n---\n\n# Scope Inside a Case\n\nA `switch` body is one block. Cases are labels, not nested blocks. That has a subtle but important consequence: if you declare a variable inside a case **without wrapping it in braces**, that variable is visible to the cases below it.\n\nThis usually compiles, but it can also bite. The biggest gotcha is that you can't declare and initialize a variable in one case and have it skip cleanly past a later case label.\n\n**What's wrong with this code?**\n\n\n```cpp\nint statusCode{2};\nswitch (statusCode) {\n case 1:\n int trackingNumber = 1001;\n std::cout << trackingNumber << std::endl;\n break;\n case 2:\n std::cout << \"Shipped\" << std::endl;\n break;\n}\n```\n\n\nThe compiler reports:\n\n\n```shell\nerror: jump to case label\n case 2:\n ^\nnote: crosses initialization of 'int trackingNumber'\n```\n\n\nThe problem is that `trackingNumber` is declared inside the switch block, so its scope extends past `case 1:` and over `case 2:`. But if `statusCode` is `2`, execution jumps directly to `case 2:`, skipping past the initialization of `trackingNumber`. C++ won't let you do that, because reading `trackingNumber` in a case where it was never initialized would be a disaster.\n\nThe fix is to give the case its own block with curly braces. That makes the variable's scope local to the case, so it doesn't leak across labels.\n\n\n```cpp\n#include \n\nint main() {\n int statusCode{2};\n switch (statusCode) {\n case 1: {\n int trackingNumber{1001};\n std::cout << \"Tracking: \" << trackingNumber << std::endl;\n break;\n }\n case 2: {\n std::cout << \"Shipped\" << std::endl;\n break;\n }\n default: {\n std::cout << \"Unknown\" << std::endl;\n break;\n }\n }\n return 0;\n}\n```\n\n\nNow `trackingNumber` lives inside the inner block of `case 1:` only. Cases that don't need a local variable don't need the braces, but it's a defensible style choice to wrap every case in braces for consistency. Many teams adopt that rule across the board.\n\n---\n\n# Switch with an Initializer (C++17)\n\nC++17 added the ability to declare and initialize a variable in the switch header itself, scoped to the switch.\n\n\n```cpp\nswitch (init-statement; condition) {\n // cases\n}\n```\n\n\nThis is the same shape as the `if` initializer added in the same standard. It's a small, focused convenience: it gives the variable a precise lifetime (only the body of the switch sees it) and keeps the call site clean.\n\nA small E-Commerce example. A function returns the current status of an order, and you want to dispatch on it without leaking the temporary into the surrounding scope.\n\n\n```cpp\n#include \n\nenum class OrderStatus { PLACED, SHIPPED, DELIVERED, CANCELLED };\n\nOrderStatus getStatus() {\n return OrderStatus::DELIVERED;\n}\n\nint main() {\n switch (auto status = getStatus(); status) {\n case OrderStatus::PLACED:\n std::cout << \"Waiting for warehouse\" << std::endl;\n break;\n case OrderStatus::SHIPPED:\n std::cout << \"On the way\" << std::endl;\n break;\n case OrderStatus::DELIVERED:\n std::cout << \"Customer received it\" << std::endl;\n break;\n case OrderStatus::CANCELLED:\n std::cout << \"Refund issued\" << std::endl;\n break;\n }\n // `status` is no longer in scope here.\n return 0;\n}\n```\n\n\nThe init-statement runs once, before the condition. The variable `status` exists for the body of the switch and nowhere else. Compared to the older form:\n\n\n```cpp\nauto status = getStatus();\nswitch (status) {\n // ...\n}\n// `status` is still in scope here, even if you'll never use it again.\n```\n\n\nthe C++17 form keeps the variable's lifetime tied to where it's actually used. That's a small win, but in code with many short switches it adds up to less noise in the surrounding scope.\n\nThe same form works with any initialization, not just `auto`. You can have multiple statements separated by commas, you can use brace initialization, and you can still pass a different expression as the condition:\n\n\n```cpp\nswitch (int code = lookupCode(productCategory); code * 10) {\n // cases test against the multiplied value\n}\n```\n\n\nThat's an unusual pattern, but the flexibility is there.\n\n---\n\n# When to Use Switch vs If/Else\n\n`switch` and `if`/`else if` overlap. Anything you can write as a switch you can also write as an if-chain, and vice versa. The choice usually comes down to readability and a small amount of performance.\n\nThe decision flow looks like this:\n\n\n```mermaid\nflowchart TD\n A[Need to choose
between branches]:::cyan --> B{Single integer
or enum value?}:::orange\n B -->|No, ranges
or expressions| C[Use if / else if]:::teal\n B -->|Yes| D{Many discrete
cases 3+?}:::orange\n D -->|No, 1-2 cases| E[if / else is
simpler]:::teal\n D -->|Yes| F[switch is
cleaner]:::green\n F --> G{Switching on
enum class?}:::orange\n G -->|Yes| H[switch wins:
compiler warns on
missing cases]:::green\n G -->|No| I[switch is still
fine, often faster]:::green\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe headline rules:\n\n- **Use `switch`** when you're dispatching on a single discrete integer or enum value and you have three or more distinct cases. The structure makes the intent clear: \"here are all the values, here's what each one does.\"\n- **Use `if`/`else if`** when you're testing ranges (`if (price < 10) ... else if (price < 50) ...`), when you need to compare different variables, when you're testing strings or floats, or when you only have one or two branches.\n\nThere's also a performance angle, but be careful not to overstate it. When the case labels are dense and numerous, the compiler often generates a **jump table**: an array indexed by the switch value where each slot holds the address of the matching case. That's O(1) dispatch, regardless of how many cases there are. An `if`/`else if` chain, by contrast, is O(n) in the number of branches in the worst case. For two or three branches that difference is invisible. For dozens, it can be measurable in a hot path.\n\nBut compilers also optimize `if` chains aggressively, and modern CPUs predict branches well. For most application code, the performance argument is a footnote. The readability argument is what should drive the choice.\n\n\n> **INFO**\n>\n> **Cost:** A `switch` with dense, contiguous integer labels often compiles to a jump table (O(1) per dispatch). Sparse or non-integer keys compile to binary searches or branching ladders instead. Don't rewrite an `if`/`else if` chain into a `switch` for speed without measuring first.\n\n\nState machines are a particularly nice fit for `switch` because each state is a discrete value with its own logic. The order-status state machine in the E-Commerce theme looks like this:\n\n\n```mermaid\nstateDiagram-v2\n [*] --> PLACED: Order created\n\n PLACED --> SHIPPED: Warehouse dispatches\n PLACED --> CANCELLED: Customer cancels\n\n SHIPPED --> DELIVERED: Carrier delivers\n SHIPPED --> CANCELLED: Lost in transit
(rare, full refund)\n\n DELIVERED --> [*]\n CANCELLED --> [*]\n\n classDef placed fill:#ffd43b,stroke:#000,color:#000\n classDef shipped fill:#00ceff,stroke:#000,color:#000\n classDef delivered fill:#69db7c,stroke:#000,color:#000\n classDef cancelled fill:#ff8787,stroke:#000,color:#000\n\n class PLACED placed\n class SHIPPED shipped\n class DELIVERED delivered\n class CANCELLED cancelled\n```\n\n\nEach state's allowed transitions become one `switch` case. A function that decides whether a transition is legal might look like:\n\n\n```cpp\n#include \n\nenum class OrderStatus { PLACED, SHIPPED, DELIVERED, CANCELLED };\n\nbool canCancel(OrderStatus current) {\n switch (current) {\n case OrderStatus::PLACED:\n case OrderStatus::SHIPPED:\n return true;\n case OrderStatus::DELIVERED:\n case OrderStatus::CANCELLED:\n return false;\n }\n return false; // unreachable for valid enum values\n}\n\nint main() {\n OrderStatus status{OrderStatus::SHIPPED};\n std::cout << \"Can cancel? \" << (canCancel(status) ? \"yes\" : \"no\") << std::endl;\n return 0;\n}\n```\n\n\nTwo cases share a body using empty-fallthrough (no statements between labels), the switch is exhaustive over the enum, and the function reads cleanly because each state's policy is written next to its label. An `if`/`else if` version would work, but the structure would be flatter and the intent slightly less obvious.\n\n---\n\n# Putting the Pieces Together\n\nA short program that uses several of the features in one place: switching on an `enum class`, the C++17 initializer form, intentional fallthrough for shared behavior, a `default` safety net, and braces around a case that declares a local.\n\n\n```cpp\n#include \n#include \n\nenum class CustomerTier { BRONZE, SILVER, GOLD, PLATINUM };\n\nCustomerTier lookupTier(const std::string& customerName) {\n if (customerName == \"Priya\") return CustomerTier::GOLD;\n if (customerName == \"Alex\") return CustomerTier::SILVER;\n return CustomerTier::BRONZE;\n}\n\nint main() {\n std::string customerName{\"Priya\"};\n\n switch (auto tier = lookupTier(customerName); tier) {\n case CustomerTier::PLATINUM:\n std::cout << \"Concierge support\" << std::endl;\n [[fallthrough]];\n case CustomerTier::GOLD: {\n int bonusPoints{500};\n std::cout << customerName << \" earns \" << bonusPoints << \" bonus points\" << std::endl;\n [[fallthrough]];\n }\n case CustomerTier::SILVER:\n std::cout << \"Free returns\" << std::endl;\n [[fallthrough]];\n case CustomerTier::BRONZE:\n std::cout << \"Free shipping\" << std::endl;\n break;\n default:\n std::cout << \"No tier\" << std::endl;\n break;\n }\n return 0;\n}\n```\n\n\nA few things to notice. The initializer in the switch header makes `tier` a switch-local variable. The Gold case declares `bonusPoints` inside its own braces because it has a local variable. Each intentional fallthrough is marked with `[[fallthrough]];` so the compiler (and the next reader of the code) knows the missing `break` is on purpose. And the `default` is at the bottom as a safety net, even though all four enumerators are handled.\n\n---\n\n# Summary\n\n- `switch` dispatches on a single integral or enumeration value: `int`, `char`, `bool`, plain `enum`, `enum class`. It does not accept `double`, `float`, or `std::string`.\n- Every case label is a jump target, not a scope. Without `break`, execution falls through into the next case. Forgetting a `break` is one of C++'s most famous bugs.\n- For intentional fallthrough, mark it with `[[fallthrough]];` (C++17). Empty-fallthrough (no statements between two labels) is fine and doesn't need the marker.\n- Always include a `default` clause unless you're switching exhaustively on an `enum class` and want the compiler's missing-enumerator warning to catch new values.\n- Wrap a case in braces (`case X: { ... }`) when you declare a variable inside it. Without braces, the variable's scope leaks into later cases and a jump can be rejected by the compiler.\n- C++17 added `switch (init-statement; condition)` to scope a helper variable to the body of the switch.\n- Choose `switch` for three-or-more discrete cases on one integer or enum value; choose `if`/`else if` for ranges, strings, floats, or two-branch decisions. Compilers can turn dense switches into jump tables, but readability is the better reason to pick one over the other.\n\nIn the next lesson, we'll move from one-shot decisions to repeated work: how to write a `for` loop, what each of its three parts does, and how to use it cleanly for the kinds of counting tasks that show up everywhere in C++ code.","pageType":"cpp"}

Switch Statement

Get Premium