{"title":"Virtual Destructors","description":null,"content":"The moment you start deleting derived objects through base pointers, the destructor stops being a sleepy member function and turns into the thing that decides whether your program leaks resources. C++ does not automatically run the right destructor when the static type of a pointer is different from the dynamic type of the object it points to. The fix is one keyword in the right place. This lesson covers what goes wrong without it, why the rule exists, and how to apply it correctly.\n\n---\n\n# The Crash Site: Deleting Through a Base Pointer\n\nA polymorphic hierarchy almost always involves a base pointer or reference, because that's the entire point of polymorphism. Code that handles `Product*` works for `DigitalProduct`, `PhysicalProduct`, and anything else that inherits from `Product`. The Polymorphism chapters in this section have leaned on that pattern repeatedly.\n\nThe trouble starts when you also own those objects through the base pointer. Sooner or later you write `delete basePtr;`. And if the base class's destructor is not virtual, that single line silently misbehaves.\n\n\n```cpp\n#include \n#include \n\nclass Product {\npublic:\n Product(std::string n) : name_(std::move(n)) {\n std::cout << \"Product(\" << name_ << \") constructed.\" << std::endl;\n }\n\n ~Product() {\n std::cout << \"Product(\" << name_ << \") destroyed.\" << std::endl;\n }\n\nprotected:\n std::string name_;\n};\n\nclass DigitalProduct : public Product {\npublic:\n DigitalProduct(std::string n, std::string url)\n : Product(std::move(n)), downloadUrl_(std::move(url)) {\n std::cout << \"DigitalProduct constructed, url = \" << downloadUrl_ << std::endl;\n }\n\n ~DigitalProduct() {\n std::cout << \"DigitalProduct destroyed, url = \" << downloadUrl_ << std::endl;\n }\n\nprivate:\n std::string downloadUrl_;\n};\n\nint main() {\n Product* p = new DigitalProduct(\"C++ Cookbook\", \"https://store.example.com/cpp-cookbook.pdf\");\n delete p;\n return 0;\n}\n```\n\n\nLook at what's missing. `DigitalProduct destroyed` never prints. The derived destructor did not run. The `downloadUrl_` string lives inside the derived part of the object, and that part of the object never got its cleanup. In this toy example, `std::string` is a member of a small object and its memory is reclaimed when the allocator releases the block, so nothing visible leaks. In real code the leak is real, and a few examples down we'll show one.\n\nTwo important details about what's happening here. First, the call to `delete` knows only what the pointer says it knows. The pointer type is `Product*`, so the compiler looks up the destructor on `Product`, finds a regular non-virtual function, and emits a direct call to `~Product`. The actual object's type doesn't enter the picture. Second, the C++ standard does not call this \"wrong output.\" It calls it **undefined behavior**: if the static type and the dynamic type differ and the destructor is not virtual, the result is whatever the implementation feels like producing. Most compilers do exactly what we saw: skip the derived destructor and free the base-sized block. Other compilers, other targets, other optimization settings can do other things.\n\n\n> **INFO**\n>\n> **Cost:** \"Undefined behavior\" is not \"behaves differently in some cases.\" It means the standard makes no promises at all. The program could leak, crash, or appear correct, and any of those can change after a recompile.\n\n\n\n```mermaid\nflowchart LR\n Code[delete basePtr
static type: Product *
actual object: DigitalProduct]:::cyan --> Q{Is Product's destructor
virtual?}:::orange\n Q -->|No| Bad[Calls only ~Product
derived members leak
undefined behavior]:::red\n Q -->|Yes| Good[Looks up ~DigitalProduct
via vtable
then chains to ~Product]:::green\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe diagram is the entire lesson in one picture. Everything else is the consequences of the right side of that diagram, and how to make sure your code ends up there.\n\n---\n\n# A Real Leak: When the Derived Class Owns a Resource\n\nThe first example didn't actually leak anything visible because `std::string` cleans itself up only when its destructor runs, and that destructor lives inside `~DigitalProduct`. With this version, the leak is impossible to ignore: the derived class owns a `std::unique_ptr` to a heap-allocated handle, and skipping the derived destructor strands that allocation.\n\n\n```cpp\n#include \n#include \n#include \n\nstruct DownloadHandle {\n std::string fileName;\n DownloadHandle(std::string f) : fileName(std::move(f)) {\n std::cout << \" [open handle for \" << fileName << \"]\" << std::endl;\n }\n ~DownloadHandle() {\n std::cout << \" [close handle for \" << fileName << \"]\" << std::endl;\n }\n};\n\nclass Product {\npublic:\n Product(std::string n) : name_(std::move(n)) {}\n ~Product() {} // non-virtual on purpose, to show the bug\nprotected:\n std::string name_;\n};\n\nclass DigitalProduct : public Product {\npublic:\n DigitalProduct(std::string n, std::string url)\n : Product(std::move(n)),\n downloadUrl_(std::move(url)),\n handle_(std::make_unique(name_)) {}\n\n ~DigitalProduct() {\n std::cout << \"~DigitalProduct running\" << std::endl;\n }\n\nprivate:\n std::string downloadUrl_;\n std::unique_ptr handle_;\n};\n\nint main() {\n std::cout << \"--- buggy: non-virtual base destructor ---\" << std::endl;\n Product* p = new DigitalProduct(\"C++ Cookbook\",\n \"https://store.example.com/cpp-cookbook.pdf\");\n delete p;\n std::cout << \"--- after delete ---\" << std::endl;\n return 0;\n}\n```\n\n\nThat's the leak. The handle opened. The handle was never closed. `~DigitalProduct` did not run, so the `std::unique_ptr` did not run its destructor, so the `DownloadHandle` it owned was not released. Imagine this is a network socket, an open file, a lock on a database row. Each delete leaks one. In an e-commerce system that ships thousands of digital downloads an hour, that's not theoretical anymore.\n\nNow change one line. Add `virtual` to `~Product`. Same `delete p;`, same everything else.\n\n\n```cpp\nclass Product {\npublic:\n Product(std::string n) : name_(std::move(n)) {}\n virtual ~Product() {} // the fix\nprotected:\n std::string name_;\n};\n```\n\n\nNow the destruction sequence runs end to end. `~DigitalProduct` fires first, which destroys the `std::unique_ptr`, which closes the `DownloadHandle`. Then `~Product` runs and the base part is cleaned up. The order matches what you'd see for any normal destruction, because that's exactly what virtual dispatch gives you here.\n\nThe whole reason `virtual` works on the destructor is the same reason it works on any other member function. The vtable mechanism from the earlier chapter on vtables looks up the right function based on the actual object's type. The destructor is just another entry in that table.\n\n---\n\n# The Rule, Stated Plainly\n\nThe rule of thumb that catches every case worth catching is short.\n\n**If a class is intended to be used polymorphically through a base pointer or reference, its destructor must be virtual.**\n\nIn practice that boils down to one even simpler heuristic, the one most teams put in their style guides:\n\n**If a class has any virtual function, give it a virtual destructor.**\n\nThe first statement is the rigorous version, the second is the version you actually apply when writing code. A class that has virtual functions is almost always one you intend to use polymorphically (otherwise why bother with the virtual?), and it's almost always one that someone, somewhere, will eventually want to `delete` through a base pointer. Adding the virtual destructor up front costs you nothing extra (the vtable already exists) and removes an entire category of future bugs.\n\nThe C++ Core Guidelines state this as rule C.35: \"A base class destructor should be either public and virtual, or protected and non-virtual.\" The second half of that rule is for cases where you want to forbid polymorphic deletion entirely. We'll come back to that.\n\n---\n\n# Modern Syntax: `virtual ~Product() = default;`\n\nMost base class destructors do nothing custom. They exist purely to be virtual so the vtable picks up the entry. The modern idiom is to default the body:\n\n\n```cpp\nclass Product {\npublic:\n Product(std::string n) : name_(std::move(n)) {}\n\n virtual ~Product() = default;\n\n // ... virtual member functions\nprotected:\n std::string name_;\n};\n```\n\n\n`= default` tells the compiler to generate the body of the destructor for you, which means \"destroy each member in reverse declaration order and stop.\" That's all most base destructors need to do. The `virtual` keyword in front is what makes the function go through the vtable, which is the part that actually matters.\n\nOnce `~Product` is virtual, the derived destructor is *implicitly* virtual too. You do not need to write `virtual` on `~DigitalProduct`. The C++11 `override` keyword is allowed on destructors and is a good habit; it doesn't change behavior, but it tells the compiler to verify that something with the same name in a base class is virtual. If you ever delete the `virtual` from the base by accident, the `override` on the derived destructor turns the mistake into a compile error.\n\n\n```cpp\nclass DigitalProduct : public Product {\npublic:\n DigitalProduct(std::string n, std::string url)\n : Product(std::move(n)), downloadUrl_(std::move(url)) {}\n\n ~DigitalProduct() override = default; // override is allowed and useful\n\nprivate:\n std::string downloadUrl_;\n};\n```\n\n\nA common shape for a base class meant for polymorphism: a virtual destructor defaulted, plus the virtual functions you want derived classes to override. A common shape for a derived class: data members that hold the actual resources, plus a defaulted destructor (the compiler-generated body is almost always right when members manage their own cleanup).\n\n---\n\n# Order of Destruction with a Virtual Destructor\n\nThe destruction order with a virtual destructor is the same as the normal C++ destruction order, just kicked off correctly. The Polymorphism magic happens only at the entry point: virtual dispatch picks the most-derived destructor. After that, the chain runs the way the language always says it does.\n\nFor `delete p;` where `p` is a `Product*` pointing to a `DigitalProduct`:\n\n1. `~DigitalProduct` body runs.\n2. `DigitalProduct`'s data members are destroyed in reverse declaration order.\n3. `~Product` body runs.\n4. `Product`'s data members are destroyed in reverse declaration order.\n5. The memory the object occupies is released.\n\nWithout `virtual`, step 1 is skipped and the destructor chain starts at step 3, which is the whole problem.\n\n\n```mermaid\nflowchart TD\n Start[delete basePtr]:::cyan --> Lookup[Virtual dispatch:
finds ~DigitalProduct]:::orange\n Lookup --> DBody[~DigitalProduct body runs]:::green\n DBody --> DMembers[DigitalProduct members destroyed
reverse declaration order]:::green\n DMembers --> BBody[~Product body runs]:::cyan\n BBody --> BMembers[Product members destroyed
reverse declaration order]:::cyan\n BMembers --> Free[Memory released]:::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\nA small program that prints every step:\n\n\n```cpp\n#include \n#include \n\nstruct Logger {\n std::string label;\n Logger(std::string s) : label(std::move(s)) {\n std::cout << \" + \" << label << std::endl;\n }\n ~Logger() {\n std::cout << \" - \" << label << std::endl;\n }\n};\n\nclass Product {\npublic:\n Product(std::string n) : name_(std::move(n)), basePart_(\"Product.\" + name_) {}\n\n virtual ~Product() {\n std::cout << \"~Product body for \" << name_ << std::endl;\n }\n\nprotected:\n std::string name_;\n Logger basePart_;\n};\n\nclass DigitalProduct : public Product {\npublic:\n DigitalProduct(std::string n, std::string url)\n : Product(std::move(n)),\n downloadUrl_(std::move(url)),\n derivedPart_(\"DigitalProduct.\" + name_) {}\n\n ~DigitalProduct() override {\n std::cout << \"~DigitalProduct body for \" << name_ << std::endl;\n }\n\nprivate:\n std::string downloadUrl_;\n Logger derivedPart_;\n};\n\nint main() {\n Product* p = new DigitalProduct(\"C++ Cookbook\",\n \"https://store.example.com/cpp-cookbook.pdf\");\n std::cout << \"--- deleting ---\" << std::endl;\n delete p;\n std::cout << \"--- done ---\" << std::endl;\n return 0;\n}\n```\n\n\nRead the bottom four lines top to bottom. `~DigitalProduct` body runs. Then `derivedPart_` (the only `Logger` declared inside `DigitalProduct`) gets destroyed. Then `~Product` body runs. Then `basePart_` (the `Logger` declared inside `Product`) gets destroyed. The `name_` string in `Product` is destroyed after that, before the memory is released; we just don't see it because `std::string` doesn't log.\n\nWhat you should not do is try to `delete` derived members from the base destructor. The base destructor doesn't know about derived state, and by the time it runs in this sequence, the derived part is already gone. Keep ownership at the level where the member is declared, and let each class's destructor handle its own members.\n\n---\n\n# The Cost of a Virtual Destructor\n\nMaking a destructor virtual has the same cost as making any other member function virtual: the class needs a vtable, every instance needs a vptr, and every call to that function goes through one extra indirection. The earlier chapter on vtables covers the mechanics. The summary is short:\n\n- If the class already has at least one other virtual function, the vtable already exists, and adding `virtual` to the destructor costs one extra slot in the vtable. That slot exists once per class, not once per object. The per-instance cost is zero extra bytes beyond what the class already pays.\n- If the class has no other virtual functions, making the destructor virtual creates the vtable from scratch and adds a vptr to every instance. On a 64-bit platform that's 8 bytes per object.\n\nThat second case is the only one worth thinking about. If your class isn't using polymorphism at all (no virtual functions, never used as a base for polymorphic deletion), adding a virtual destructor is paying for something you'll never use.\n\n\n> **INFO**\n>\n> **Cost:** Adding `virtual` to a destructor in a class with no other virtual functions adds 8 bytes per instance (the vptr) on most 64-bit platforms. Not free, but also not what you'd be optimizing first.\n\n\nThe right way to think about the trade-off: if the class is polymorphic, you already pay for a vtable, and the virtual destructor is a marginal cost on top of an existing cost. The benefit is that `delete basePtr;` is safe instead of undefined behavior. That's a great trade. If the class is not polymorphic, you don't need a virtual destructor at all, so the trade doesn't come up.\n\n---\n\n# Smart Pointers Don't Save You (Mostly)\n\nBeginners sometimes assume that switching from `new`/`delete` to smart pointers makes the virtual destructor problem disappear. It doesn't, at least not for `std::unique_ptr`.\n\n\n```cpp\n#include \n#include \n#include \n\nclass Product {\npublic:\n Product(std::string n) : name_(std::move(n)) {}\n ~Product() { std::cout << \"~Product\" << std::endl; } // not virtual\nprotected:\n std::string name_;\n};\n\nclass DigitalProduct : public Product {\npublic:\n DigitalProduct(std::string n, std::string url)\n : Product(std::move(n)), url_(std::move(url)) {}\n ~DigitalProduct() { std::cout << \"~DigitalProduct\" << std::endl; }\nprivate:\n std::string url_;\n};\n\nint main() {\n std::unique_ptr p = std::make_unique(\n \"C++ Cookbook\", \"https://store.example.com/cpp-cookbook.pdf\");\n // p goes out of scope here. Same problem as raw delete.\n return 0;\n}\n```\n\n\nSame bug, same undefined behavior. The `std::unique_ptr` deletes the held pointer using the static type it was templated on, which is `Product` here. Internally, `~unique_ptr` calls something equivalent to `delete static_cast(rawPtr)`, which is exactly the line we already know is broken when `~Product` isn't virtual. Smart pointers are a thin wrapper around the same `delete`, so the same rule applies: if you'll hold a `unique_ptr` whose contained object might be a derived type, `~Base` must be virtual.\n\n`std::shared_ptr` is the one exception, and even there you should not lean on it. A `shared_ptr` records its deleter in its internal control block at construction time, using the type the `shared_ptr` was constructed *from*, not the type it was stored as.\n\n\n```cpp\nstd::shared_ptr p = std::make_shared(\n \"C++ Cookbook\", \"https://store.example.com/cpp-cookbook.pdf\");\n// On reset, shared_ptr's control block calls delete on a DigitalProduct*\n// even though the user-facing type is shared_ptr.\n```\n\n\nThis works, and it works even when `~Product` is not virtual, because the control block remembers it needs to call `~DigitalProduct`. It's a real escape hatch, occasionally useful in templated code where you don't control the base class.\n\nDon't rely on it as a substitute for a virtual destructor. Two reasons. First, the protection vanishes the moment someone constructs the `shared_ptr` from a `Product*` instead of a `DigitalProduct*`, which is easy to do by accident:\n\n\n```cpp\nDigitalProduct* raw = new DigitalProduct(...);\nProduct* base = raw;\nstd::shared_ptr p(base); // control block now records ~Product, not ~DigitalProduct\n```\n\n\nSecond, the rest of your code, every `unique_ptr`, every raw `delete`, every base pointer in a container, still has the original bug. Making the destructor virtual fixes all of them at once. Relying on `shared_ptr`'s magic fixes only the cases that happen to be `make_shared`'d.\n\nThe general guideline is the simple one: if you intend a class for polymorphic use, make its destructor virtual, and don't bet on the smart-pointer implementation to bail you out.\n\n---\n\n# The Opposite Case: When You Don't Want a Virtual Destructor\n\nNot every class wants to pay the vtable tax, and not every class is a polymorphic base. A `Coupon` value type that holds a code and a discount percent has no inheritance, no virtual methods, no need for runtime dispatch. Giving it a virtual destructor adds 8 bytes per object for absolutely no benefit.\n\n\n```cpp\n// No virtual destructor here. Don't add one.\nclass Coupon {\npublic:\n Coupon(std::string code, double percent)\n : code_(std::move(code)), percent_(percent) {}\n\n std::string code() const { return code_; }\n double percent() const { return percent_; }\n\nprivate:\n std::string code_;\n double percent_;\n};\n```\n\n\nThe rule cuts both ways. The same logic that says \"if it's polymorphic, make the destructor virtual\" also says \"if it's not polymorphic, don't.\" A value-type class that's never inherited from, never deleted through a base pointer, simply has no use for a virtual destructor.\n\nA nuance: even a class that does have a base class doesn't necessarily need a virtual destructor, if the inheritance is being used for code reuse rather than runtime dispatch. The strict version of the rule is about *polymorphic deletion* specifically. The reason most style guides round it up to \"any class with a virtual function\" is that those classes are almost certainly used polymorphically in practice. If you genuinely have a class with virtual functions but no one ever deletes it through a base pointer, you can argue against the virtual destructor, but the argument rarely survives contact with a code review.\n\nThe C++ Core Guideline C.35 gives you the precise escape: if you want to forbid polymorphic deletion, declare the destructor `protected` and non-virtual:\n\n\n```cpp\nclass Mixin {\npublic:\n virtual void hook() = 0;\nprotected:\n ~Mixin() = default; // protected: callers cannot delete via Mixin*\n};\n```\n\n\nThat makes `delete basePtr` a compile error when `basePtr` is a `Mixin*`. The class can still have virtual methods, can still be inherited from, just not deleted through the base. This is unusual and you'll mostly see it in libraries that want to be very explicit about ownership. For everyday code, the rule remains the simple one.\n\n---\n\n# Pure Virtual Destructors (Brief Recap)\n\nThe previous chapter on pure virtual functions covers this in detail; one quick reminder. A destructor can be declared pure virtual, which makes the class abstract:\n\n\n```cpp\nclass Product {\npublic:\n virtual ~Product() = 0; // pure virtual destructor\n};\n\nProduct::~Product() = default; // but it still needs a body\n```\n\n\nThe pure virtual declaration prevents anyone from creating a `Product` directly, the same way any pure virtual function does. The body is still required because every derived destructor chains into the base destructor, so the base destructor's body has to exist somewhere. This pattern is the standard way to make a class abstract when you don't have any other pure virtual method that fits naturally. The point here is that pure virtual destructors do exist and are useful in exactly this niche.\n\n---\n\n# Putting It All Together: A Small Polymorphic Catalog\n\nThe pieces in one place. A `Product` base with a virtual destructor and a virtual `describe` method, three derived classes with their own state, a `std::vector>` that owns them. Each derived destructor cleans up its own resources, the base destructor cleans up the base. Run with `-fsanitize=address` and there are no leaks.\n\n\n```cpp\n#include \n#include \n#include \n#include \n\nclass Product {\npublic:\n Product(std::string n, double p) : name_(std::move(n)), price_(p) {}\n\n virtual ~Product() = default;\n\n virtual void describe() const {\n std::cout << name_ << \" ($\" << price_ << \")\" << std::endl;\n }\n\nprotected:\n std::string name_;\n double price_;\n};\n\nclass DigitalProduct : public Product {\npublic:\n DigitalProduct(std::string n, double p, std::string url)\n : Product(std::move(n), p), downloadUrl_(std::move(url)) {\n std::cout << \" open download for \" << name_ << std::endl;\n }\n\n ~DigitalProduct() override {\n std::cout << \" close download for \" << name_ << std::endl;\n }\n\n void describe() const override {\n std::cout << \"[digital] \" << name_ << \" ($\" << price_\n << \") -> \" << downloadUrl_ << std::endl;\n }\n\nprivate:\n std::string downloadUrl_;\n};\n\nclass PhysicalProduct : public Product {\npublic:\n PhysicalProduct(std::string n, double p, double weightKg)\n : Product(std::move(n), p), weightKg_(weightKg) {}\n\n ~PhysicalProduct() override {\n std::cout << \" release packaging for \" << name_ << std::endl;\n }\n\n void describe() const override {\n std::cout << \"[physical] \" << name_ << \" ($\" << price_\n << \", \" << weightKg_ << \" kg)\" << std::endl;\n }\n\nprivate:\n double weightKg_;\n};\n\nint main() {\n std::vector> catalog;\n catalog.push_back(std::make_unique(\n \"C++ Cookbook\", 29.99, \"https://store.example.com/cpp-cookbook.pdf\"));\n catalog.push_back(std::make_unique(\n \"Coffee Mug\", 9.99, 0.4));\n\n std::cout << \"--- describing ---\" << std::endl;\n for (const auto& p : catalog) {\n p->describe();\n }\n\n std::cout << \"--- catalog goes out of scope ---\" << std::endl;\n return 0;\n}\n```\n\n\nThe vector destroys its elements in order (front to back) when it goes out of scope. Each `unique_ptr` deletes its held pointer, virtual dispatch picks the right destructor, and the derived cleanup runs before the base cleanup chains in. Remove the `virtual` on `~Product`, and `close download` and `release packaging` both disappear from the output, replaced silently by undefined behavior. The single keyword is the only thing standing between this working version and a leaking one.\n\n---\n\n# Summary\n\n- Deleting a derived object through a base pointer is undefined behavior unless the base class's destructor is virtual. On most compilers the visible result is that the derived destructor never runs and any resources owned by the derived part are leaked.\n- The rule of thumb: if a class has any virtual function, give it a virtual destructor. The strict version is \"if the class is meant to be deleted polymorphically through a base pointer.\" In practice, those two cases line up so closely that the simpler rule is the one most teams apply.\n- The modern syntax for a base class destructor that has no special cleanup is `virtual ~ClassName() = default;`. The `virtual` puts the destructor in the vtable; the `= default` lets the compiler generate the body.\n- Once a base destructor is virtual, every derived destructor is implicitly virtual. Writing `virtual` on the derived destructor is unnecessary, but writing `override` is a good habit because the compiler then verifies the base destructor really is virtual.\n- The destruction sequence with a virtual destructor is the standard C++ destruction order, just dispatched correctly: derived destructor body, derived members in reverse declaration order, base destructor body, base members in reverse declaration order.\n- Cost: a virtual destructor adds one entry to the per-class vtable, which is free if the class already has any other virtual function. For a class with no other virtual functions, it adds a vptr (8 bytes on 64-bit) to every instance, so don't add it to non-polymorphic classes.\n- Smart pointers do not save you. `std::unique_ptr` calls `delete` through `Base*`, so it has the exact same requirement on `~Base` being virtual. `std::shared_ptr` records its deleter in the control block and is sometimes more forgiving, but treating that as a substitute for a virtual destructor is poor practice.\n- Pure virtual destructors (`virtual ~Base() = 0;` with an out-of-line body) make a class abstract while still giving every derived class a clean destruction chain.\n\nIn the next chapter, we'll cover **RTTI**, the part of C++ that lets you ask \"what is the actual dynamic type of this object?\" at runtime through `typeid` and `dynamic_cast`. RTTI is the other half of the polymorphism toolkit: virtual functions answer \"what should this object do?\" and RTTI answers \"what is this object, exactly?\"","pageType":"cpp"}

Virtual Destructors

Get Premium