{"title":"Virtual Functions","description":null,"content":"The `virtual` keyword is the single switch that turns a C++ member function into something the runtime can dispatch on. Without it, a call through a base pointer or reference picks the implementation at compile time and runs the base version. With it, the same call defers the decision to runtime and runs whichever version belongs to the actual object. This lesson digs into what `virtual` does to a function, how to call the base version from inside an override, and two corners of the language where virtual dispatch behaves in ways that surprise people.\n\n---\n\n# What `virtual` Actually Changes\n\nStripped to one sentence: `virtual` changes a member function from being statically resolved (compiler picks based on the pointer/reference type) to being dynamically dispatched (runtime picks based on the actual object).\n\nThe keyword goes in the **base** class, before the return type, on the method's declaration. Once the base function is virtual, the same function in every derived class is virtual too, automatically. This is a small detail worth pinning down because it affects how you write derived classes.\n\n\n```cpp\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() { // virtual goes HERE in the base\n price = price * 0.90;\n }\n};\n\nclass DigitalProduct : public Product {\npublic:\n DigitalProduct(std::string n, double p) : Product(std::move(n), p) {}\n\n void applyDiscount() override { // no 'virtual' needed, it's implicit\n price = price * 0.70;\n }\n};\n\nint main() {\n DigitalProduct ebook(\"C++ Cookbook\", 50.0);\n Product* p = &ebook;\n p->applyDiscount();\n std::cout << ebook.name << \": $\" << ebook.price << std::endl;\n return 0;\n}\n```\n\n\nThe call `p->applyDiscount()` goes through a `Product*`, but it lands in `DigitalProduct::applyDiscount` because `Product::applyDiscount` is virtual. The price drops by 30%, not 10%.\n\nThe rule is: `virtual` belongs on the base method's declaration, and the only thing it changes about that method is the dispatch strategy. The function body, the parameter list, the return type, everything else stays the same.\n\n---\n\n# Once Virtual, Always Virtual\n\nHere is a wrinkle that trips up people coming from other languages: in C++, virtualness is **inherited**. If a method is virtual in the base, it is virtual in every derived class that overrides it, whether you write the `virtual` keyword on the derived declaration or not.\n\n\n```cpp\n#include \n#include \n\nclass Product {\npublic:\n virtual void describe() const {\n std::cout << \"A product\" << std::endl;\n }\n};\n\nclass DigitalProduct : public Product {\npublic:\n void describe() const override { // implicitly virtual\n std::cout << \"A digital product\" << std::endl;\n }\n};\n\nclass EbookProduct : public DigitalProduct {\npublic:\n void describe() const override { // still implicitly virtual\n std::cout << \"An ebook\" << std::endl;\n }\n};\n\nint main() {\n EbookProduct ebook;\n Product* p = &ebook;\n p->describe();\n return 0;\n}\n```\n\n\n`Product::describe` is the only declaration that says `virtual`, but `DigitalProduct::describe` and `EbookProduct::describe` are virtual all the way down. The call through `Product*` correctly dispatches to `EbookProduct::describe`, three levels deep.\n\nSo why isn't `virtual` written on the derived declarations? Two reasons. First, it's redundant: the language already knows the function is virtual, so repeating the keyword adds nothing. Second, the modern C++ convention is to write `override` on the derived declaration instead. `override` was added in C++11 specifically to mark intent and let the compiler verify that the derived function actually overrides a virtual base function. The rule of thumb is \"write `virtual` in the base, write `override` in every derived class.\"\n\nYou **could** write `virtual void describe() const override;` in a derived class. It compiles. It just carries two keywords doing one job's worth of work. Pick `override`.\n\n---\n\n# Calling the Base Version from an Override\n\nA common pattern: the derived override wants to do everything the base does, plus a little extra on top. The natural-looking solution is to call the same-named function from inside the override. That breaks badly. The unqualified call resolves to the override you're already inside, and the function recurses into itself until the stack runs out.\n\nThe correct way is to qualify the call with the base class name: `Base::method()`. The qualified call bypasses virtual dispatch and invokes the named version directly.\n\nE-commerce example. `Product::applyDiscount` takes 10% off any product. `DigitalProduct` overrides it to take the base 10% first, then knocks off another 20% because digital goods cost almost nothing to deliver.\n\n\n```cpp\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; // 10% off\n }\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 Product::applyDiscount(); // first, the base 10% off\n price = price * 0.80; // then an extra 20% off\n }\n};\n\nint main() {\n DigitalProduct ebook(\"C++ Cookbook\", 100.0);\n ebook.applyDiscount();\n std::cout << ebook.name << \": $\" << ebook.price << std::endl;\n return 0;\n}\n```\n\n\nThe math: \\$100 multiplied by 0.90 gives \\$90, then 0.80 of that gives \\$72. The two discounts stack because the override delegates to the base first and then adds its own logic. Writing `applyDiscount()` instead of `Product::applyDiscount()` would have called `DigitalProduct::applyDiscount` again, which would call itself, and so on. A reliable way to crash the program in one line.\n\n\n```mermaid\nflowchart LR\n A[ebook.applyDiscount called]:::cyan --> B[DigitalProduct::applyDiscount enters
price equals 100]:::orange\n B --> C[Product::applyDiscount
qualified call
price becomes 90]:::green\n C --> D[Back in derived override
multiply by 0.80
price becomes 72]:::green\n D --> E[Return to caller]:::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 `Base::method()` syntax is the only way to invoke a base implementation that has been overridden in the current class. It works for any level of the hierarchy too. If `EbookProduct` extends `DigitalProduct` and wants the digital discount on top of the bundle bonus, it writes `DigitalProduct::applyDiscount()`. You name the class whose version you want, and you get exactly that version.\n\n\n> **INFO**\n>\n> **Cost:** A qualified `Base::method()` call is a direct (non-virtual) call. There is no vtable lookup, even when the function is virtual. The compiler emits the same code it would for a regular static method call.\n\n\n---\n\n# A Teaser: Pure Virtual Functions\n\nSometimes the base class shouldn't really have an implementation. `Product::applyDiscount` taking a generic 10% off is fine as a default, but in some hierarchies the base has no sensible default at all. What should `Shape::area` return for a \"shape\" that has no actual geometry? What should `PaymentMethod::charge` do when \"payment method\" is an abstract idea, not a concrete way to pay?\n\nC++ has a syntax for this: declare the function `virtual` and assign it to zero. That makes it a **pure virtual function**, and the class that contains it is automatically an **abstract class** that cannot be instantiated directly.\n\n\n```cpp\n#include \n#include \n\nclass PaymentMethod {\npublic:\n std::string name;\n PaymentMethod(std::string n) : name(std::move(n)) {}\n\n virtual void charge(double amount) = 0; // pure virtual\n virtual ~PaymentMethod() = default;\n};\n\nclass CreditCardPayment : public PaymentMethod {\npublic:\n CreditCardPayment() : PaymentMethod(\"Credit Card\") {}\n\n void charge(double amount) override {\n std::cout << \"Charging $\" << amount << \" to credit card.\" << std::endl;\n }\n};\n\nint main() {\n // PaymentMethod p(\"Generic\"); // ERROR: cannot instantiate abstract class\n CreditCardPayment cc;\n PaymentMethod* pm = &cc;\n pm->charge(49.99);\n return 0;\n}\n```\n\n\nThe `= 0` at the end of the declaration is the syntax. It means \"this function has no body in this class, and any concrete derived class must provide one.\" Trying to instantiate `PaymentMethod` directly produces a compile error. Pure virtual functions are how C++ expresses interfaces: the base says \"subclasses must implement this,\" the derived class delivers, and code that talks to the base type gets polymorphic behavior for free.\n\nFor now, the takeaway is the syntax and the idea: `= 0` makes a function abstract, and the class becomes abstract along with it.\n\n---\n\n# Pitfall 1: Virtual Functions with Default Arguments\n\nThis one is the kind of bug that survives code review because the code looks right, the behavior looks plausible, and the actual issue only matters in one specific call shape. The rule is simple but counterintuitive:\n\n**Default arguments are resolved at compile time using the static type. The function body is resolved at runtime using the dynamic type.**\n\nRead that again. Two halves of the same call get resolved using two different types. When the defaults differ between base and derived, the result is a function call that picks one set of arguments and one body, where each comes from a different class. Output: confusion.\n\n\n```cpp\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(double percent = 10.0) {\n std::cout << \"Product: taking \" << percent << \"% off \" << name << std::endl;\n price = price * (1.0 - percent / 100.0);\n }\n};\n\nclass DigitalProduct : public Product {\npublic:\n DigitalProduct(std::string n, double p) : Product(std::move(n), p) {}\n\n void applyDiscount(double percent = 30.0) override {\n std::cout << \"Digital: taking \" << percent << \"% off \" << name << std::endl;\n price = price * (1.0 - percent / 100.0);\n }\n};\n\nint main() {\n DigitalProduct ebook(\"C++ Cookbook\", 100.0);\n Product* p = &ebook;\n\n p->applyDiscount(); // surprise: which default applies?\n std::cout << ebook.name << \": $\" << ebook.price << std::endl;\n return 0;\n}\n```\n\n\nTwo surprises in three lines of output. The function that ran was the **derived** `DigitalProduct::applyDiscount` (you can see \"Digital:\" in the print), but the default value for `percent` was **10.0**, which is the base's default, not the derived's 30.0. That's why the price dropped by only 10% even though the digital override ran.\n\nWhat happened: the compiler looked at the call `p->applyDiscount()` and saw `p` had static type `Product*`. It filled in the missing argument from `Product::applyDiscount`'s default (`percent = 10.0`). Then it emitted a virtual call. At runtime, the vtable lookup found `DigitalProduct::applyDiscount` and ran that, but the argument was already baked in as 10.0 from the compile-time decision.\n\n\n```mermaid\nflowchart TD\n Call[p->applyDiscount
p is Product *
actual object: DigitalProduct]:::cyan --> Split{Two parts of the call
get resolved differently}:::orange\n\n Split --> Args[Default arguments
resolved at compile time
using static type Product *]:::red\n Split --> Body[Function body
resolved at runtime
using dynamic type DigitalProduct]:::green\n\n Args --> R1[percent equals 10.0
from Product default]:::red\n Body --> R2[Runs DigitalProduct::applyDiscount
but with percent equals 10.0]:::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 classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe simplest fix is the one most teams reach for: **don't give virtual functions default arguments at all**. If the base has no defaults and the derived has no defaults, there is nothing to mismatch. Callers always pass the argument explicitly, and the question of \"which default wins\" never comes up.\n\n\n```cpp\nclass Product {\npublic:\n virtual void applyDiscount(double percent) { // no default\n price = price * (1.0 - percent / 100.0);\n }\n};\n\nclass DigitalProduct : public Product {\npublic:\n void applyDiscount(double percent) override { // no default\n price = price * (1.0 - percent / 100.0);\n }\n};\n```\n\n\nIf you really need a \"default discount\" concept, express it without leaning on language-level defaults. Two clean options: provide a non-virtual overload that calls the virtual one with a sensible value, or expose a separate function with an obvious name.\n\n\n```cpp\nclass Product {\npublic:\n virtual void applyDiscount(double percent) {\n price = price * (1.0 - percent / 100.0);\n }\n\n void applyDefaultDiscount() { // non-virtual wrapper\n applyDiscount(10.0); // virtual call, single source of truth\n }\n};\n```\n\n\nNow the \"default\" is part of the function name, not buried in the parameter list. There is no signature mismatch to argue about, and the dispatch is unambiguous.\n\n---\n\n# Pitfall 2: Calling Virtual Functions from Constructors and Destructors\n\nInside a base class's constructor or destructor, virtual calls do not dispatch to the derived override. They dispatch to the base's own version. This is by design, not a bug, and the reason is a memory-safety guarantee that costs you a feature you may not have wanted in the first place.\n\nThe rule, stated precisely: **during construction and destruction of an object, the dynamic type of the object is the type of the constructor or destructor currently running.** While `Product`'s constructor runs, the object **is** a `Product`. The `DigitalProduct` parts haven't been initialized yet (or, during destruction, have already been torn down), so dispatching to `DigitalProduct::applyDiscount` would touch members that don't exist yet.\n\nConcrete example. `Product` calls a virtual `describe()` from its constructor, expecting derived classes to plug in their own version.\n\n\n```cpp\n#include \n#include \n\nclass Product {\npublic:\n std::string name;\n\n Product(std::string n) : name(std::move(n)) {\n std::cout << \"Product ctor: \";\n describe(); // virtual call inside constructor\n }\n\n virtual ~Product() {\n std::cout << \"Product dtor: \";\n describe(); // virtual call inside destructor\n }\n\n virtual void describe() const {\n std::cout << \"I am a Product named \" << name << std::endl;\n }\n};\n\nclass DigitalProduct : public Product {\npublic:\n DigitalProduct(std::string n) : Product(std::move(n)) {\n std::cout << \"DigitalProduct ctor finished\" << std::endl;\n }\n\n ~DigitalProduct() override {\n std::cout << \"DigitalProduct dtor running\" << std::endl;\n }\n\n void describe() const override {\n std::cout << \"I am a DigitalProduct named \" << name << std::endl;\n }\n};\n\nint main() {\n DigitalProduct ebook(\"C++ Cookbook\");\n return 0;\n}\n```\n\n\nNotice both the constructor and destructor lines say \"I am a Product.\" The author of `DigitalProduct` probably expected \"I am a DigitalProduct\" both times, since the object **is** a `DigitalProduct` and `describe` is virtual. But during `Product`'s constructor, the derived parts haven't been built yet, so the language wires the virtual call to `Product::describe`. During `Product`'s destructor, the derived parts have already been torn down, so the same rule applies in reverse.\n\n\n```mermaid\nflowchart TD\n Start[DigitalProduct ebook created]:::cyan --> P1[Product constructor begins
dynamic type: Product]:::orange\n P1 --> P2[Virtual call to describe
runs Product::describe
not the override]:::red\n P2 --> P3[Product constructor ends]:::orange\n P3 --> D1[DigitalProduct constructor body runs
dynamic type now DigitalProduct]:::green\n D1 --> Live[Object lives as DigitalProduct
virtual calls dispatch to override]:::green\n Live --> DD1[DigitalProduct destructor runs first
tears down derived parts]:::orange\n DD1 --> DD2[Product destructor begins
dynamic type back to Product]:::red\n DD2 --> DD3[Virtual call to describe
runs Product::describe again]:::red\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 red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nWhy does the language work this way? Imagine the alternative. If `Product`'s constructor called `DigitalProduct::describe`, and `DigitalProduct::describe` tried to read a member that lives in `DigitalProduct` itself, it would be reading uninitialized memory. The language refuses to let that happen, even at the cost of a feature that would otherwise seem natural. The same logic applies in reverse for destructors: by the time `Product`'s destructor runs, anything that was specific to `DigitalProduct` has already been destroyed.\n\nThe practical consequence: **do not call virtual functions from constructors or destructors expecting derived behavior.** If you find yourself wanting that pattern, two reliable alternatives exist.\n\n**Option 1: Two-step construction.** Build the object, then call an initializer that runs after construction completes. The initializer is a normal member function, called on a fully constructed object, and virtual dispatch works as expected.\n\n\n```cpp\nclass Product {\npublic:\n std::string name;\n Product(std::string n) : name(std::move(n)) {}\n\n void init() { // call after construction\n describe(); // now dispatches to derived\n }\n\n virtual void describe() const {\n std::cout << \"A product\" << std::endl;\n }\n};\n```\n\n\n**Option 2: Pass the behavior in.** Hand the constructor a function object or a callback that contains the per-type behavior, sidestepping virtual dispatch entirely. This is heavier machinery and is overkill for most situations, but it's a clean option when the construction-time customization point genuinely matters.\n\n---\n\n# Performance: What Virtual Costs\n\nVirtual functions are not free, but they are cheap, and the cost is well-understood. A virtual call adds one level of indirection compared to a direct call. The generated code reads a hidden pointer from the object (the **vptr**) to find the class's table of function pointers (the **vtable**), then reads the right entry from that table to find the actual function to call.\n\nIn a non-virtual call:\n\n\n```shell\ncall Product::applyDiscount\n```\n\n\nIn a virtual call:\n\n\n```shell\nread vptr from object\nread function pointer from vtable\ncall through that function pointer\n```\n\n\nOn modern CPUs, this is a few extra instructions and one or two extra memory accesses. The accesses usually hit L1 cache because the vtable is small and frequently used. In tight loops where the same function is called millions of times, the cost can show up in benchmarks. In normal application code, it's invisible.\n\nThree things worth knowing about the cost:\n\n\n| Concern | Reality |\n|---------|---------|\n| Per-call overhead | A few extra cycles, usually negligible |\n| Memory per object | One extra pointer (the vptr) per polymorphic instance |\n| Inlining | Virtual calls usually can't be inlined, because the compiler doesn't know which function will run |\n\n\nThe third item matters more than the first two for hot code. Inlining is one of the compiler's most effective optimizations, and it depends on knowing the function at compile time. A virtual call hides that knowledge. Some modern compilers can \"devirtualize\" a call when they can prove the dynamic type (a local object whose type never changes, for example), and then inline normally, but this is best-effort.\n\n\n> **INFO**\n>\n> **Cost:** For a tight inner loop where the same virtual function is called billions of times on objects whose type is known statically, sometimes it pays to bypass virtual dispatch with a templated approach (CRTP). For everyday code, just write `virtual` and move on.\n\n\nFor now, all you need is the mental model: one hidden pointer per object, one table per class, one extra hop per call.\n\n---\n\n# Putting It Together\n\nA small e-commerce hierarchy that uses everything in this lesson. `Product` is the base with a virtual `applyDiscount` and a virtual `describe`. `DigitalProduct` calls the base discount and adds an extra cut on top. `SubscriptionProduct` overrides both. A loop iterates over a vector of `Product*` and processes each item without knowing the concrete type.\n\n\n```cpp\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 virtual ~Product() = default;\n\n virtual void applyDiscount() {\n price = price * 0.90; // 10% off baseline\n }\n\n virtual void describe() const {\n std::cout << name << \": $\" << price << std::endl;\n }\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 Product::applyDiscount(); // 10% base first\n price = price * 0.80; // then 20% on top\n }\n\n void describe() const override {\n std::cout << name << \" (digital): $\" << price << std::endl;\n }\n};\n\nclass SubscriptionProduct : public Product {\npublic:\n SubscriptionProduct(std::string n, double p) : Product(std::move(n), p) {}\n\n void applyDiscount() override {\n price = price * 0.50; // 50% off first cycle\n }\n\n void describe() const override {\n std::cout << name << \" (subscription): $\" << price << \"/month\" << std::endl;\n }\n};\n\nint main() {\n Product mug(\"Coffee Mug\", 20.0);\n DigitalProduct ebook(\"C++ Cookbook\", 100.0);\n SubscriptionProduct plan(\"Cloud Storage\", 10.0);\n\n std::vector catalog = {&mug, &ebook, &plan};\n\n for (Product* item : catalog) {\n item->applyDiscount();\n item->describe();\n }\n return 0;\n}\n```\n\n\nThe loop only knows about `Product*`. Three different discount rules, three different description formats, no `if`-chains. Each object's vptr points to the right vtable, the runtime picks the right function, and you get genuine polymorphism for the price of one extra indirection per call.\n\nTwo specific things to notice in this example. First, `DigitalProduct::applyDiscount` uses `Product::applyDiscount()` to delegate the baseline discount to the base, then adds its own cut. No infinite recursion because of the qualifier. Second, there are no default arguments on any virtual function, which sidesteps the pitfall entirely. There are no virtual calls in the constructors or destructors either, which sidesteps the other pitfall.\n\n---\n\n# Summary\n\n- `virtual` on a base method's declaration changes its dispatch strategy from compile-time (static type) to runtime (dynamic type). The function body, parameters, and return type are otherwise unchanged.\n- Once a function is virtual in any base, every override in any derived class is automatically virtual too. You don't need to repeat the keyword; use `override` on the derived declaration instead.\n- Inside an override, call the base version with the qualified syntax `Base::method()`. The unqualified call resolves to the override itself and recurses forever.\n- A pure virtual function is declared with `= 0` at the end. The class becomes abstract and cannot be instantiated directly.\n- Pitfall: virtual functions with default arguments mix static and dynamic types in one call. The default value comes from the static type, the function body from the dynamic type. Do not give defaults to virtual functions.\n- Pitfall: virtual calls inside constructors and destructors do not dispatch to derived overrides. During base construction or destruction, the object's dynamic type is the base type. Use a separate `init()` method called after construction if you need polymorphic setup.\n- A virtual call costs one extra indirection through the vtable, plus one hidden pointer (the vptr) per object. This is usually invisible in normal code but matters for hot inner loops where inlining is critical.\n\nThe next lesson opens the black box on what `virtual` actually compiles to: the vtable layout, the vptr in each object, how constructors set up the vptr, and what happens when a virtual call is made through a base pointer. Once you've seen the mechanism, the rules in this lesson (especially the constructor and destructor pitfall) make more concrete sense.","pageType":"cpp"}

Virtual Functions

Get Premium