{"title":"Polymorphism Basics","description":null,"content":"Polymorphism means \"many forms.\" In C++, it lets one piece of calling code work with many different types of objects, where each type decides for itself how to respond. The payoff is fewer `if/else` chains, fewer type tags, and code that handles new cases without you rewriting the call site. This chapter sets up the vocabulary and the motivating problem; the next two chapters dig into the two flavors of polymorphism C++ actually gives you.\n\n---\n\n# What Polymorphism Actually Means\n\nThe word comes from Greek roots that translate to \"many shapes.\" In code, it shows up wherever a single name (a function call, an operator, a method) does different work depending on what it's acting on.\n\nA small concrete picture before any theory. An E-Commerce checkout has to charge the customer. The charge function should not care whether the customer is paying with a credit card, a digital wallet, or UPI. It should just say \"charge this order\" and let the right thing happen.\n\n\n```cpp\n#include \n#include \n\nvoid chargeCreditCard(double amount) {\n std::cout << \"Charging $\" << amount << \" to credit card\" << std::endl;\n}\n\nvoid chargeWallet(double amount) {\n std::cout << \"Deducting $\" << amount << \" from wallet balance\" << std::endl;\n}\n\nvoid chargeUpi(double amount) {\n std::cout << \"Sending UPI request for $\" << amount << std::endl;\n}\n\nvoid checkout(const std::string& method, double amount) {\n if (method == \"card\") {\n chargeCreditCard(amount);\n } else if (method == \"wallet\") {\n chargeWallet(amount);\n } else if (method == \"upi\") {\n chargeUpi(amount);\n } else {\n std::cout << \"Unknown payment method\" << std::endl;\n }\n}\n\nint main() {\n checkout(\"card\", 49.99);\n checkout(\"wallet\", 12.50);\n checkout(\"upi\", 199.00);\n return 0;\n}\n```\n\n\nThe code works. It also has a problem that grows every time the business adds a payment method. Each new option means another branch in `checkout`. Add gift cards, store credit, BNPL, crypto, and the `if/else` ladder becomes a wall. Every team that calls `checkout` is also locked into knowing every payment method by name, which leaks the decision into every caller.\n\nPolymorphism is the language feature that lets you replace that ladder with a single line: `payment.charge(amount)`. The variable `payment` could be a credit card, a wallet, or anything else, and the right `charge` runs without `checkout` ever asking what type it actually is.\n\n\n```mermaid\nflowchart LR\n Caller[checkout calls
payment.charge amount]:::cyan --> Dispatch{Which type
of payment?}:::orange\n Dispatch -->|Credit Card| CC[Charge credit card]:::green\n Dispatch -->|Wallet| W[Deduct from wallet]:::green\n Dispatch -->|UPI| U[Send UPI request]:::green\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe caller stays simple. The decision lives with the types, not with the caller. That is the entire point of polymorphism.\n\n---\n\n# Why `if/else` on a Type Tag Is the Wrong Tool\n\nThe payment example above is one shape of the same anti-pattern. Three more E-Commerce examples that scream \"polymorphism would be better.\"\n\n**Notifications.** An order moves through several states (placed, shipped, delivered) and each state sends a different notification: an SMS, an email, a push, or a printed shipping label. A naive design pushes a type tag through a single function:\n\n\n```cpp\n#include \n#include \n\nenum class NotifyKind { Sms, Email, Push, ShippingLabel };\n\nvoid sendNotification(NotifyKind kind, const std::string& message) {\n switch (kind) {\n case NotifyKind::Sms:\n std::cout << \"[SMS] \" << message << std::endl;\n break;\n case NotifyKind::Email:\n std::cout << \"[Email] \" << message << std::endl;\n break;\n case NotifyKind::Push:\n std::cout << \"[Push] \" << message << std::endl;\n break;\n case NotifyKind::ShippingLabel:\n std::cout << \"[Label printed] \" << message << std::endl;\n break;\n }\n}\n\nint main() {\n sendNotification(NotifyKind::Sms, \"Your order has shipped\");\n sendNotification(NotifyKind::Email, \"Receipt for order #1042\");\n return 0;\n}\n```\n\n\nIt runs. It also has three problems that compound over time.\n\n\n| Problem | What it looks like |\n| --- | --- |\n| Every new notification kind edits one shared function | Adding WhatsApp means touching `sendNotification`, the enum, and any other dispatcher. |\n| The `switch` doesn't know when it's incomplete | Drop a new enum value and forget to add a case, and you get silent fallthrough or a compile warning at best. |\n| Each branch can't carry its own state | An email needs an SMTP server, an SMS needs a phone number. The function signature has to accept all of them or fall back to globals. |\n\n\n**Discounts per product type.** A `Product` base with `DigitalProduct`, `PhysicalProduct`, and `SubscriptionProduct` derivatives each need to apply a discount differently. A digital product can discount aggressively because delivery is nearly free. A physical product has to cover shipping, so it discounts less. A subscription product can throw a big first-cycle promo. Same idea, same shape:\n\n\n```cpp\n#include \n#include \n\nenum class ProductKind { Digital, Physical, Subscription };\n\ndouble applyDiscount(ProductKind kind, double price) {\n if (kind == ProductKind::Digital) {\n return price * 0.70;\n } else if (kind == ProductKind::Physical) {\n return price * 0.85;\n } else {\n return price * 0.50;\n }\n}\n\nint main() {\n std::cout << \"Digital: $\" << applyDiscount(ProductKind::Digital, 50.0) << std::endl;\n std::cout << \"Physical: $\" << applyDiscount(ProductKind::Physical, 20.0) << std::endl;\n std::cout << \"Subscription: $\" << applyDiscount(ProductKind::Subscription, 10.0) << std::endl;\n return 0;\n}\n```\n\n\n**Printing receipts.** An order summary has to print itself in different formats: a console line, an HTML email body, or a JSON blob for the mobile app. Same data, three formats, one function full of branches.\n\nThree different problems, one shared structure. In each case:\n\n1. There is a set of related types or categories.\n2. There is one operation (`charge`, `notify`, `discount`, `print`) that varies per type.\n3. The caller wants to invoke that operation without spelling out the type.\n\nThe `if/else` ladder works for two cases. It bends for three. It breaks at five. And it forces every caller to know the full enum, which means adding a new case requires touching every dispatcher in the codebase.\n\n\n> **INFO**\n>\n> **Cost:** Branching on a type tag isn't slow by itself, the real cost is maintenance. A polymorphic call dispatches in a constant number of cycles regardless of how many subtypes exist. A `switch` over an enum grows code size with each added case and, worse, scatters the dispatch logic across every function that takes the tag.\n\n\nThe fix has the same shape every time: pull each type's behavior into its own class, give them a common interface, and let the language do the dispatch.\n\n---\n\n# The Bridge from Inheritance to Polymorphism\n\nThe Inheritance section walked through inheritance: a derived class shares fields and methods with its base, you can pass a derived object where a base reference or pointer is expected, and you can replace a base method by redeclaring it in the derived class. The last point came with a warning: replacing a non-virtual method only changes what happens when you call through the derived type directly. The base version still runs through a base pointer or reference.\n\nThat warning is the door to polymorphism. The whole point of inheriting from `Product` is so that other code (a shopping cart, a recommendation engine, a search filter) can hold `Product*` or `Product&` and not care which subtype is underneath. If those callers always get the base version of every method, then inheritance is a code-reuse tool and nothing more.\n\nPolymorphism is what makes inheritance pay off. It is the rule that says \"when you call a method on a base reference, the actual object's version runs.\" Without it, the catalog loop from the inheritance section doesn't work the way the names suggest. With it, the loop becomes the centerpiece of an extensible design.\n\n\n```cpp\n#include \n#include \n#include \n#include \n\nclass Product {\npublic:\n std::string name;\n double price;\n\n Product(std::string n, double p) : name(std::move(n)), price(p) {}\n\n virtual void applyDiscount() {\n price = price * 0.90;\n }\n\n virtual ~Product() = default;\n};\n\nclass DigitalProduct : public Product {\npublic:\n DigitalProduct(std::string n, double p) : Product(std::move(n), p) {}\n\n void applyDiscount() override {\n price = price * 0.70;\n }\n};\n\nclass PhysicalProduct : public Product {\npublic:\n PhysicalProduct(std::string n, double p) : Product(std::move(n), p) {}\n\n void applyDiscount() override {\n price = price * 0.85;\n }\n};\n\nint main() {\n std::vector> catalog;\n catalog.push_back(std::make_unique(\"C++ Cookbook\", 50.0));\n catalog.push_back(std::make_unique(\"Coffee Mug\", 20.0));\n\n for (auto& p : catalog) {\n p->applyDiscount();\n std::cout << p->name << \": $\" << p->price << std::endl;\n }\n return 0;\n}\n```\n\n\nThe loop talks to `Product*`. Two different `applyDiscount` implementations run. The loop doesn't check types, doesn't switch on a tag, doesn't even know that `DigitalProduct` and `PhysicalProduct` exist. That separation is the whole game. The `virtual` keyword in the base and the `override` keyword in the derived classes wire it up.\n\nFor now, the mental model is enough: inheritance gives you the shared shape, polymorphism gives you behavior that varies by actual type without the caller noticing.\n\n---\n\n# The Two Flavors of Polymorphism in C++\n\nC++ ships two distinct forms of polymorphism, and most surprises beginners hit come from confusing them. A high-level map first, then a chapter each for the details.\n\n\n| Flavor | Other names | Decided at | Mechanism in C++ |\n| --- | --- | --- | --- |\n| Compile-time polymorphism | Static polymorphism | Compile time | Function overloading, operator overloading, templates |\n| Runtime polymorphism | Dynamic polymorphism, late binding | Runtime | Virtual functions through a base pointer or reference |\n\n\nThe two flavors solve different problems and pay for themselves in different ways. Both are polymorphism in the broad sense (one name, many behaviors), but the moment when \"which behavior\" gets decided is completely different.\n\n**Compile-time polymorphism** is when the compiler can figure out, while reading your source code, exactly which function or method should run. There is no runtime cost beyond a normal function call, because the call is fully resolved before the program ever starts. Overloaded functions are the simplest example. The compiler sees `add(2, 3)` versus `add(2.5, 3.5)` and picks the right overload based on argument types.\n\n\n```cpp\n#include \n#include \n\ndouble addPrices(double a, double b) {\n return a + b;\n}\n\nint addQuantities(int a, int b) {\n return a + b;\n}\n\nstd::string addLabels(const std::string& a, const std::string& b) {\n return a + \" + \" + b;\n}\n\nint main() {\n std::cout << addPrices(19.99, 5.50) << std::endl;\n std::cout << addQuantities(3, 4) << std::endl;\n std::cout << addLabels(\"Mug\", \"Cookbook\") << std::endl;\n return 0;\n}\n```\n\n\nAll three calls look the same at the call site, just with different argument types. The compiler reads the types and picks one of three concrete functions. Each call is a direct, fully-resolved jump to a known function in the binary. There is no table lookup, no indirection, no surprise. The \"polymorphism\" lives entirely in the source code; the machine code sees three unrelated calls.\n\n**Runtime polymorphism** is what you reach for when the compiler can't make the decision. It can't know which subclass of `Product` is sitting behind a `Product*` until the program is actually running and that pointer has been assigned. The mechanism that lets the right method still run is a runtime lookup using virtual functions. The cost is a small indirection per call; the benefit is that you can add new subclasses without touching the calling code.\n\n\n```cpp\n#include \n#include \n#include \n#include \n\nclass Notification {\npublic:\n virtual void send(const std::string& message) = 0;\n virtual ~Notification() = default;\n};\n\nclass SmsNotification : public Notification {\npublic:\n void send(const std::string& message) override {\n std::cout << \"[SMS] \" << message << std::endl;\n }\n};\n\nclass EmailNotification : public Notification {\npublic:\n void send(const std::string& message) override {\n std::cout << \"[Email] \" << message << std::endl;\n }\n};\n\nint main() {\n std::vector> channels;\n channels.push_back(std::make_unique());\n channels.push_back(std::make_unique());\n\n for (auto& c : channels) {\n c->send(\"Your order has shipped\");\n }\n return 0;\n}\n```\n\n\nThe loop calls `send` on a `Notification*`. The actual object behind each pointer determines which version of `send` runs. The decision happens at runtime, on every call, because the compiler can't tell from the source which concrete type the loop is iterating over right now. That is runtime polymorphism.\n\n\n```mermaid\nflowchart TD\n Code[Source code calls
obj.method args]:::cyan --> Q{Can the compiler
determine the exact
method to call?}:::orange\n Q -->|Yes| Static[Compile-time polymorphism
overloading templates]:::green\n Q -->|No| Dynamic[Runtime polymorphism
virtual functions vtable]:::teal\n Static --> Direct[Direct call
resolved before runtime]:::green\n Dynamic --> Indirect[Indirect call
resolved during execution]:::teal\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe diagram captures the decision criterion: who has enough information to choose, the compiler or the running program? When the compiler can choose, you get compile-time polymorphism with zero runtime overhead. When only the program knows (because it depends on data, user input, or what's been pushed into a container), you pay the small cost of a runtime lookup and get the ability to plug in new types later without recompiling the caller.\n\n---\n\n# Where the Two Flavors Show Up in C++\n\nA quick map of which features go in which bucket.\n\n\n| Feature | Flavor |\n| --- | --- |\n| Function overloading | Compile-time |\n| Operator overloading | Compile-time |\n| Templates (function and class) | Compile-time |\n| Virtual functions | Runtime |\n| Pure virtual functions and abstract classes | Runtime |\n| `dynamic_cast` and `typeid` | Runtime |\n\n\nA small concrete example of compile-time polymorphism that you have probably already used without thinking about it: `std::cout << x` works for `int`, `double`, `std::string`, and a dozen other types because the standard library has overloaded `operator<<` for each one. The compiler picks the right overload based on what you put on the right-hand side. No virtual functions involved.\n\n\n```cpp\n#include \n#include \n\nint main() {\n int quantity = 3;\n double price = 19.99;\n std::string product = \"Coffee Mug\";\n\n std::cout << quantity << \" x \" << product << \" at $\" << price << std::endl;\n return 0;\n}\n```\n\n\nThree different argument types, three different overloads of `operator<<`, all resolved before the program runs. Now contrast with a runtime example, a `processPayment` that handles any payment method through a single base type:\n\n\n```cpp\n#include \n#include \n#include \n\nclass Payment {\npublic:\n virtual void process(double amount) = 0;\n virtual ~Payment() = default;\n};\n\nclass CreditCardPayment : public Payment {\npublic:\n void process(double amount) override {\n std::cout << \"Charging $\" << amount << \" to credit card\" << std::endl;\n }\n};\n\nclass WalletPayment : public Payment {\npublic:\n void process(double amount) override {\n std::cout << \"Deducting $\" << amount << \" from wallet\" << std::endl;\n }\n};\n\nclass UpiPayment : public Payment {\npublic:\n void process(double amount) override {\n std::cout << \"Sending UPI request for $\" << amount << std::endl;\n }\n};\n\nvoid processOrder(Payment& payment, double total) {\n payment.process(total);\n}\n\nint main() {\n CreditCardPayment card;\n WalletPayment wallet;\n UpiPayment upi;\n\n processOrder(card, 49.99);\n processOrder(wallet, 12.50);\n processOrder(upi, 199.00);\n return 0;\n}\n```\n\n\nCompare this to the `if/else` ladder from earlier in the chapter. Same output. Three big differences in the code that produced it:\n\n\n| Concern | `if/else` ladder | Polymorphic version |\n| --- | --- | --- |\n| Adding a new payment type | Edit `checkout` plus every dispatcher | Add a new subclass, done |\n| The caller's knowledge | Must know every method by string tag | Only knows `Payment` |\n| Where the behavior lives | Inside a switch statement | Inside the class that owns it |\n\n\nThe `processOrder` function does not name `CreditCardPayment`, `WalletPayment`, or `UpiPayment`. Nothing in the call site needs to change when you add `GiftCardPayment` or `BnplPayment`. That decoupling is what runtime polymorphism buys.\n\n\n> **INFO**\n>\n> **Cost:** Each virtual call costs one indirect lookup on top of a normal call: read the hidden vptr from the object, index into the vtable, jump through the function pointer. A few extra cycles. The compiler can sometimes prove the type and \"devirtualize\" the call back to a direct one.\n\n\nBy the end of this section, you should be able to read code that uses a base pointer to a derived object and predict exactly which method runs, why, and what it costs. You should also be able to look at an `if/else` ladder on a type tag and see the polymorphic refactor that hides inside it.\n\n---\n\n# A Side-by-Side Refactor\n\nA longer worked example that compares the two designs end to end. The setup: an order placed on an E-Commerce site sends out several notifications when its state changes. An SMS goes to the customer's phone. An email goes to their inbox with the receipt. A push notification fires on the mobile app. A printed label gets queued at the warehouse.\n\nThe procedural version uses a tag and a switch.\n\n\n```cpp\n#include \n#include \n#include \n\nenum class Channel { Sms, Email, Push, Label };\n\nstruct Notice {\n Channel channel;\n std::string message;\n};\n\nvoid deliver(const Notice& n) {\n switch (n.channel) {\n case Channel::Sms:\n std::cout << \"[SMS to phone] \" << n.message << std::endl;\n break;\n case Channel::Email:\n std::cout << \"[Email to inbox] \" << n.message << std::endl;\n break;\n case Channel::Push:\n std::cout << \"[Push to app] \" << n.message << std::endl;\n break;\n case Channel::Label:\n std::cout << \"[Label printed] \" << n.message << std::endl;\n break;\n }\n}\n\nint main() {\n std::vector outbox = {\n {Channel::Sms, \"Order #1042 shipped\"},\n {Channel::Email, \"Receipt for order #1042\"},\n {Channel::Push, \"Out for delivery\"},\n {Channel::Label, \"Ship to 221B Baker Street\"}\n };\n\n for (const auto& n : outbox) {\n deliver(n);\n }\n return 0;\n}\n```\n\n\nThe code works for four channels. The structure scales badly. Every channel-specific behavior has to fit through the `Notice` struct, so the moment SMS needs a phone number and email needs an SMTP server, the struct grows fields that only one branch uses. Every new channel forces an edit to `deliver`. The polymorphic version moves the per-channel logic into the per-channel class.\n\n\n```cpp\n#include \n#include \n#include \n#include \n\nclass Notice {\npublic:\n virtual void deliver(const std::string& message) = 0;\n virtual ~Notice() = default;\n};\n\nclass SmsNotice : public Notice {\n std::string phone;\npublic:\n SmsNotice(std::string p) : phone(std::move(p)) {}\n void deliver(const std::string& message) override {\n std::cout << \"[SMS to \" << phone << \"] \" << message << std::endl;\n }\n};\n\nclass EmailNotice : public Notice {\n std::string address;\npublic:\n EmailNotice(std::string a) : address(std::move(a)) {}\n void deliver(const std::string& message) override {\n std::cout << \"[Email to \" << address << \"] \" << message << std::endl;\n }\n};\n\nclass PushNotice : public Notice {\n std::string deviceId;\npublic:\n PushNotice(std::string d) : deviceId(std::move(d)) {}\n void deliver(const std::string& message) override {\n std::cout << \"[Push to \" << deviceId << \"] \" << message << std::endl;\n }\n};\n\nint main() {\n std::vector> outbox;\n outbox.push_back(std::make_unique(\"+1-555-0142\"));\n outbox.push_back(std::make_unique(\"buyer@example.com\"));\n outbox.push_back(std::make_unique(\"device-91a3\"));\n\n for (auto& n : outbox) {\n n->deliver(\"Order #1042 shipped\");\n }\n return 0;\n}\n```\n\n\nEach `Notice` subclass carries its own state (a phone number, an email address, a device id). The loop doesn't know about any of that, it just calls `deliver`. Adding a `WhatsAppNotice` later means writing one class and pushing it onto `outbox`. No existing file needs to change. That property, *open for extension, closed for modification*, is the practical upshot of polymorphism in design terms.\n\nThe two versions produce equivalent output for this small example, but they age very differently as the system grows.\n\n\n| Dimension | `switch` version | Polymorphic version |\n| --- | --- | --- |\n| Lines that change to add a channel | `deliver`, enum, struct | One new class |\n| Per-channel state | Forced into a shared struct or globals | Lives inside the class |\n| Testing one channel in isolation | Hard, deliver knows them all | Easy, the class stands alone |\n| Reading the dispatch logic | One long switch, all in one spot | Distributed across classes |\n\n\nThe last row cuts both ways. A `switch` puts every branch in one place, which is convenient when you want to see all options at once. The polymorphic design spreads the branches across files, which can make the system harder to skim. Most real codebases land on polymorphism because the cost of editing one shared dispatcher every time anything changes outweighs the benefit of having the cases collected in one file.\n\n---\n\n# Why Polymorphism Is Worth a Whole Section\n\nA reasonable question at this point: function overloading was a chapter in the Functions section, virtual functions are a chapter in this section, templates are a section of their own. Why does polymorphism need any treatment beyond the sum of those parts?\n\nTwo reasons.\n\nFirst, the concept is bigger than any single feature. Polymorphism is the principle that one name produces many behaviors. C++ provides multiple features that implement that principle, and the trade-offs between them matter when you design real systems. A function overload, a template, and a virtual function all express \"this name has many forms\", but they decide *which form* at different times and pay different costs. Picking the right one is a design skill, not just a language skill.\n\nSecond, the runtime flavor has a thicket of rules that don't fit neatly into \"here's the `virtual` keyword.\" There are pure virtual functions, virtual destructors, the vtable, the vptr, object slicing, function hiding, RTTI, dynamic casts. Each of these is a small concept on its own. Together they form a coherent model, and that model is the lingua franca of object-oriented C++. A single chapter on `virtual` would skip every interesting question.\n\nThis chapter is the orientation. The rest of the section is the detailed map.\n\n\n> **INFO**\n>\n> **Cost:** The mental model is more expensive than the runtime cost. Once you have the model, predicting how a polymorphic program behaves is mechanical. Before you have the model, the behavior of a virtual call looks like compiler magic. The internals lessons that follow exist to take the magic out.\n\n\n---\n\n# Summary\n\n- Polymorphism means \"many forms\": one name produces different behavior depending on the type involved. In E-Commerce code, it shows up wherever the same call (`charge`, `notify`, `applyDiscount`, `print`) should do something different per payment, channel, or product type.\n- Polymorphism replaces `if/else` chains and `switch` statements over type tags. Each new type adds its own class instead of forcing edits to every dispatcher in the codebase.\n- C++ ships two distinct flavors: compile-time polymorphism (the compiler picks the call) and runtime polymorphism (the running program picks the call).\n- Compile-time polymorphism shows up in function overloading, operator overloading, and templates. It costs nothing at runtime because the dispatch happens before the program starts.\n- Runtime polymorphism shows up through virtual functions called through a base pointer or reference. It costs one indirect lookup per call and pays back with the ability to add new subclasses without touching the caller.\n- Inheritance gives you the shared shape between related types. Polymorphism turns that shape into a real abstraction by letting callers work with the base type alone.\n- The two flavors are not in competition. Templates and virtual functions both appear in idiomatic C++, often in the same class. The right choice depends on whether the type is known at compile time or only at runtime.\n\nThe next chapter zooms in on compile-time polymorphism: how function overloading, operator overloading, and templates let the compiler pick the right call from a set of candidates, all before any code actually runs.","pageType":"cpp"}

Polymorphism Basics

Get Premium