{"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 fallthrough behavior, 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 is a marker inside one big block. That detail matters when declaring variables inside cases, covered below.\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 cannot 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 a small integer, so it works cleanly. This suits 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 a small integer constant. The compiler accepts this.\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 about missing cases.\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 cannot 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`. To get the underlying integer (to print it, log it, or send it across a wire), cast back explicitly with `static_cast`:\n\n\n```cpp\nint statusCode = static_cast(status);\n```\n\n\nWhen a `switch` on an `enum class` covers every enumerator without a `default`, most compilers (g++, clang++) warn if a new enumerator is added later and not handled. That is one of the strongest reasons to switch on enums.\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 is no way to build a jump table from one. To dispatch on string values, use an `if`/`else if` chain, a `std::unordered_map>`, or map the strings to an enum first and switch on that.\n\n---\n\n# Fallthrough\n\nEvery case label is 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 well-known bug patterns in C and C++.\n\n**What is 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 is 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 fallthrough is intended.\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\nCompilers 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# Intentional Fallthrough and `[[fallthrough]]`\n\nSometimes two cases should share the same body. The standard 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 is nothing to fall through past.\n\nThe harder case is when one branch does some work and then deliberately continues into the next. That is where the `[[fallthrough]]` attribute, added in C++17, applies.\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: the missing `break` is on purpose. It also tells the compiler to suppress its fallthrough warning for that one case.\n\nA few details:\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. It cannot appear in the middle of a case body.\n- It is only meaningful right before a `case` or `default` label. Anywhere else, it is a syntax error.\n\nWithout `[[fallthrough]]`, compilers with the warning enabled flag the missing `break` as a likely bug. With it, the compiler accepts the intent. 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 the switch is on an `enum class` and the compiler should warn about missing enumerators. The `default` is the safety net for unanticipated values. Without it, unexpected input slips through.\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\nOne case where `default` can be omitted: switching over an `enum class` whose enumerators are handled exhaustively. Tools like `-Wswitch-enum` will warn if a new enumerator is added without updating the switch, which is the desired safety check.\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 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: a variable declared inside a case **without wrapping it in braces** is visible to the cases below it.\n\nThis usually compiles, but it can cause errors. The biggest issue is that declaring and initializing a variable in one case and skipping past a later case label is not allowed.\n\n**What is 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:`. If `statusCode` is `2`, execution jumps directly to `case 2:`, skipping past the initialization of `trackingNumber`. C++ does not allow that, because reading `trackingNumber` in a case where it was never initialized would be unsafe.\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 does not 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 do not need a local variable do not need the braces, but wrapping every case in braces for consistency is a defensible style choice. 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 is 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 the dispatch should not leak 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 is actually used. That is 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`. Multiple statements can be separated by commas, brace initialization works, and a different expression can still be passed 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 is 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 that can be written as a switch can also be written 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`** for dispatching on a single discrete integer or enum value with three or more distinct cases. The structure makes the intent clear: \"here are all the values, here is what each one does.\"\n- **Use `if`/`else if`** for testing ranges (`if (price < 10) ... else if (price < 50) ...`), comparing different variables, testing strings or floats, or for one or two branches.\n\nThere is also a performance angle, but it is easy to overstate. 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 is 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\nCompilers 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\nA `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. Do not rewrite an `if`/`else if` chain into a `switch` for speed without measuring first.\n\nState machines are a fit for `switch` because each state is a discrete value with its own logic. The order-status state machine in the E-Commerce theme:\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:\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 less obvious.\n\n---\n\n# Putting the Pieces Together\n\nA short program that uses several 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 note. 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) sees that the missing `break` is on purpose. And the `default` is at the bottom as a safety net, even though all four enumerators are handled.","pageType":"cpp"}

Switch Statement

Get Premium