{"title":"Destructors","description":null,"content":"A constructor sets a freshly built object up. A destructor does the opposite job at the other end of the object's life: it runs automatically right before the object is destroyed and is the one place to release whatever the object was holding. For a `ShoppingCart` that holds heap-allocated items, a `FileReceipt` that owns an open file handle, or an `Order` that tracks a network connection, the destructor guarantees those resources get cleaned up no matter how the object goes out of scope.\n\n---\n\n# Why Destructors Exist\n\nEvery non-trivial object has a creation side and a cleanup side. The constructor handles creation: allocate memory, open a file, increment a counter, lock a mutex. None of that work is automatic; the code does it explicitly. Cleanup has the same problem in reverse. Memory needs to be freed. Files need to be closed. Counters need to be decremented. Code that only runs cleanup in some paths leaks resources in the other paths.\n\nConsider a cart that owns a heap-allocated array of items. The constructor allocates the array. Without a destructor, every code path that destroys the cart has to remember to free the array first, which is unreliable:\n\n\n```cpp\n#include \n\nstruct ShoppingCart {\n int* itemIds;\n int count;\n};\n\nint main() {\n ShoppingCart cart;\n cart.itemIds = new int[3]{101, 102, 103};\n cart.count = 3;\n\n std::cout << \"Cart has \" << cart.count << \" items.\" << std::endl;\n // forgot to call `delete[] cart.itemIds;` before returning\n return 0;\n}\n```\n\n\nThe program prints the line and exits, but the heap allocation is never released. On a long-running server, repeating this pattern leaks memory until the process gets killed. The fix is to attach cleanup directly to the object's life cycle, so that destroying the `ShoppingCart` automatically frees the array. That's exactly what a destructor does.\n\n---\n\n# Destructor Syntax\n\nA destructor is a special member function. The name is the class name with a tilde in front, it takes no parameters, and it has no return type, not even `void`. A class can have only one destructor.\n\n\n```cpp\n#include \n\nclass ShoppingCart {\npublic:\n ShoppingCart() {\n std::cout << \"Cart created.\" << std::endl;\n }\n\n ~ShoppingCart() {\n std::cout << \"Cart destroyed.\" << std::endl;\n }\n};\n\nint main() {\n ShoppingCart cart;\n std::cout << \"Cart is in use.\" << std::endl;\n return 0;\n}\n```\n\n\nThree things to note. The destructor is named `~ShoppingCart`, matching the class name. It has no parameters, so a destructor can't be overloaded or take arguments. And no code calls it directly. The compiler inserts the call automatically when the object's lifetime ends.\n\nWithout a written destructor, the compiler generates one. The generated destructor calls the destructor of each data member in reverse declaration order and then ends. For a class that only holds value-type members like `std::string` or `int`, the generated destructor is enough, because `std::string` already cleans itself up. A user-defined destructor is only needed when the class owns a resource that the compiler doesn't know how to release on its own.\n\n---\n\n# When the Destructor Runs\n\nA destructor runs automatically when an object's lifetime ends. There are three common situations where that happens, and they cover almost every object that any program writes.\n\nThe first is scope exit for a local variable. When a function returns or a block ends, every local variable declared in that scope is destroyed in reverse order of construction.\n\n\n```cpp\n#include \n#include \n\nclass Product {\npublic:\n Product(const std::string& name) : name_(name) {\n std::cout << \"Product(\" << name_ << \") constructed.\" << std::endl;\n }\n\n ~Product() {\n std::cout << \"Product(\" << name_ << \") destroyed.\" << std::endl;\n }\n\nprivate:\n std::string name_;\n};\n\nvoid processOrder() {\n Product mouse(\"Wireless Mouse\");\n std::cout << \"Processing order...\" << std::endl;\n} // mouse destroyed here, right before processOrder returns\n\nint main() {\n std::cout << \"Before processOrder\" << std::endl;\n processOrder();\n std::cout << \"After processOrder\" << std::endl;\n return 0;\n}\n```\n\n\nThe destructor for `mouse` fires on the closing brace of `processOrder`, before control returns to `main`. The runtime doesn't wait for the program to end; the object is cleaned up the moment its scope closes.\n\nThe second case is `delete` on a heap-allocated object. An object created with `new` lives on the heap and stays there until the code frees it. `delete` is the operation that triggers the destructor for a heap object.\n\n\n```cpp\n#include \n#include \n\nclass Product {\npublic:\n Product(const std::string& name) : name_(name) {\n std::cout << \"Product(\" << name_ << \") constructed on heap.\" << std::endl;\n }\n\n ~Product() {\n std::cout << \"Product(\" << name_ << \") destroyed.\" << std::endl;\n }\n\nprivate:\n std::string name_;\n};\n\nint main() {\n Product* p = new Product(\"Mechanical Keyboard\");\n std::cout << \"Using the product...\" << std::endl;\n delete p; // destructor runs, then memory is freed\n std::cout << \"After delete.\" << std::endl;\n return 0;\n}\n```\n\n\nThe destructor runs as part of `delete`. A forgotten `delete` means the destructor never runs and the memory leaks. Smart pointers exist to make this kind of cleanup automatic, but for now, the rule is plain: every `new` needs a matching `delete`.\n\nThe third case is a container clearing or removing elements. When a `std::vector` goes out of scope, the vector's destructor visits every stored `Product` and destroys it. The same thing happens on `clear()`, `pop_back()`, or when the vector reallocates during a `push_back` that exceeds its capacity (the moved-from objects get destroyed).\n\n\n```cpp\n#include \n#include \n#include \n\nclass Product {\npublic:\n Product(const std::string& name) : name_(name) {\n std::cout << \" + \" << name_ << std::endl;\n }\n\n ~Product() {\n std::cout << \" - \" << name_ << std::endl;\n }\n\nprivate:\n std::string name_;\n};\n\nint main() {\n {\n std::cout << \"Building catalog:\" << std::endl;\n std::vector catalog;\n catalog.reserve(3);\n catalog.emplace_back(\"Mouse\");\n catalog.emplace_back(\"Keyboard\");\n catalog.emplace_back(\"Cable\");\n std::cout << \"Catalog ready (\" << catalog.size() << \" items).\" << std::endl;\n } // catalog goes out of scope here\n std::cout << \"After block.\" << std::endl;\n return 0;\n}\n```\n\n\nWhen the inner block ends, the vector itself is destroyed, and as part of that, each `Product` inside it gets its destructor called. The same pattern applies to `clear()`, which destroys every element without destroying the vector itself.\n\nDestroying a `std::vector` runs the destructor for every element, which is O(n) in the size of the vector. For trivially destructible types (`int`, `double`, raw pointers), the compiler skips this loop entirely and the cleanup is O(1) wall time.\n\nThe full picture of where destructor calls come from:\n\n\n```mermaid\nflowchart LR\n A[Object created]:::cyan --> B{Where does it live?}:::orange\n B -->|Local variable| C[Destructor runs at
end of scope]:::green\n B -->|Member of class| D[Destructor runs
with parent object]:::teal\n B -->|Heap, raw new| E[Destructor runs
on delete]:::yellow\n B -->|Element in container| F[Destructor runs
on clear or removal]:::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 teal fill:#38d9a9,stroke:#000,color:#000\n classDef yellow fill:#ffd43b,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nThe flowchart covers the common paths. Every C++ object ends up matching one of these four cases.\n\n---\n\n# Order of Destruction (LIFO)\n\nWhen multiple objects live in the same scope, the order they get destroyed is the reverse of the order they were created. This is the same Last-In-First-Out pattern that local variables follow in any block-structured language.\n\n\n```cpp\n#include \n#include \n\nclass Resource {\npublic:\n Resource(const std::string& label) : label_(label) {\n std::cout << \"Constructed: \" << label_ << std::endl;\n }\n\n ~Resource() {\n std::cout << \"Destroyed: \" << label_ << std::endl;\n }\n\nprivate:\n std::string label_;\n};\n\nint main() {\n Resource cart(\"Cart\");\n Resource customer(\"Customer\");\n Resource order(\"Order\");\n\n std::cout << \"--- doing work ---\" << std::endl;\n return 0;\n}\n```\n\n\n`Cart` was constructed first, so it is destroyed last. `Order` was constructed last, so it is destroyed first. The compiler tracks this order using the same stack discipline it uses for function calls.\n\nThe same rule applies to data members inside a class. When the parent object is destroyed, its members are destroyed in reverse declaration order. This matters when one member depends on another being alive during cleanup.\n\n\n```mermaid\nflowchart LR\n A[Cart
built 1st]:::cyan\n B[Customer
built 2nd]:::orange\n C[Order
built 3rd]:::green\n\n A --> B --> C\n\n C2[Order
destroyed 1st]:::red\n B2[Customer
destroyed 2nd]:::yellow\n A2[Cart
destroyed 3rd]:::teal\n\n C2 --> B2 --> A2\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 classDef yellow fill:#ffd43b,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe construction order goes from left to right, and the destruction order goes from left to right of the bottom row, which is the reverse of construction. The shape is a stack: things go in at one end and come out at the other.\n\nFor dynamically allocated arrays, the rule still holds. `delete[] products` runs the destructor on every element starting from the highest index down to index zero.\n\n\n```cpp\nProduct* products = new Product[3]{...};\n// later\ndelete[] products;\n// destructor called for products[2], then products[1], then products[0]\n```\n\n\nThis LIFO ordering is part of why C++ can guarantee deterministic cleanup. There is no runtime decision about when an object dies; the order is built into the language.\n\n---\n\n# RAII: The Core Motivation\n\nThe phrase **RAII** stands for **Resource Acquisition Is Initialization**, which is awkward but describes a powerful idea: tie every acquired resource to the lifetime of an object. The constructor acquires the resource. The destructor releases it. When the object dies, the resource is released automatically, no matter how control left the scope (normal return, exception, early `return`, anything).\n\nA `CartItems` class that owns a heap-allocated array of item IDs is the classic example. The constructor allocates the array, and the destructor frees it. Once that pairing is in place, the surrounding code doesn't have to remember to release anything.\n\n\n```cpp\n#include \n\nclass CartItems {\npublic:\n CartItems(int capacity) : capacity_(capacity), ids_(new int[capacity]) {\n std::cout << \"Allocated array for \" << capacity_ << \" items.\" << std::endl;\n }\n\n ~CartItems() {\n std::cout << \"Freeing array of \" << capacity_ << \" items.\" << std::endl;\n delete[] ids_;\n }\n\n void set(int index, int id) { ids_[index] = id; }\n int get(int index) const { return ids_[index]; }\n\nprivate:\n int capacity_;\n int* ids_;\n};\n\nvoid checkout() {\n CartItems items(3);\n items.set(0, 101);\n items.set(1, 102);\n items.set(2, 103);\n std::cout << \"First item id: \" << items.get(0) << std::endl;\n} // items destructor runs here, freeing the array\n\nint main() {\n checkout();\n std::cout << \"Back in main.\" << std::endl;\n return 0;\n}\n```\n\n\nThe caller never writes `delete[]`. The destructor handles it. If `checkout` exited early through an exception or an extra `return`, the destructor would still fire and the array would still get freed. That's what makes RAII a property of the language rather than a convention to remember. The Memory Management section of the course covers RAII in full, including how it interacts with exceptions and how smart pointers package this pattern into reusable types.\n\nThe destructor runs every time the object is destroyed, even on the fast path. For a class that owns a heap allocation, that means one `delete[]` per object. The runtime cost is the cost of `delete[]` itself; the conceptual cost is zero, because the alternative is a leak.\n\n---\n\n# The Ctor-Acquires / Dtor-Releases Pattern\n\nThe constructor-acquires, destructor-releases pairing isn't limited to memory. It works for any resource that needs cleanup: open files, network sockets, database handles, mutex locks, reference counts, anything that has a \"release this when done\" rule.\n\nA class that tracks a temporary discount applied to a cart is a clean example. The constructor applies the discount, the destructor removes it, and the discount stays applied for exactly as long as the helper object is alive.\n\n\n```cpp\n#include \n\nclass Cart {\npublic:\n double total = 100.0;\n};\n\nclass TemporaryDiscount {\npublic:\n TemporaryDiscount(Cart& cart, double percent)\n : cart_(cart), percent_(percent) {\n cart_.total = cart_.total * (1.0 - percent_ / 100.0);\n std::cout << \"Applied \" << percent_ << \"% discount. Total: $\"\n << cart_.total << std::endl;\n }\n\n ~TemporaryDiscount() {\n cart_.total = cart_.total / (1.0 - percent_ / 100.0);\n std::cout << \"Removed \" << percent_ << \"% discount. Total: $\"\n << cart_.total << std::endl;\n }\n\nprivate:\n Cart& cart_;\n double percent_;\n};\n\nint main() {\n Cart cart;\n std::cout << \"Start total: $\" << cart.total << std::endl;\n {\n TemporaryDiscount holiday(cart, 10.0);\n std::cout << \"During discount: $\" << cart.total << std::endl;\n }\n std::cout << \"End total: $\" << cart.total << std::endl;\n return 0;\n}\n```\n\n\nThe same pattern repeats in every well-written C++ resource type: `std::lock_guard` locks a mutex on construction and unlocks it on destruction, `std::ofstream` opens a file on construction and closes it on destruction, `std::unique_ptr` allocates on construction and frees on destruction. Each one follows the same shape: do the acquire step in the constructor, do the release step in the destructor, and let scope handle the rest.\n\nThe takeaway is the symmetry. Whatever the constructor sets up, the destructor must tear down. If the constructor allocates memory, the destructor must `delete` it. If the constructor opens a connection, the destructor must close it. Breaking the pairing produces leaks; preserving it makes the resource invisible to surrounding code.\n\n---\n\n# Virtual Destructors (Brief Mention)\n\nWhen a class serves as a base class for inheritance and a derived object can be deleted through a pointer to the base, the destructor in the base class must be marked `virtual`. Without `virtual`, only the base destructor runs, and any resources the derived class owns leak.\n\n\n```cpp\nclass Payment {\npublic:\n virtual ~Payment() = default; // virtual destructor\n};\n\nclass CreditCardPayment : public Payment {\npublic:\n ~CreditCardPayment() {\n // cleans up credit-card-specific resources\n }\n};\n\nint main() {\n Payment* p = new CreditCardPayment();\n delete p; // works correctly only because ~Payment is virtual\n return 0;\n}\n```\n\n\nThe rule of thumb is short: a class with any virtual function needs a virtual destructor.\n\nFor a class with no `virtual` functions and no intended base-class role, a virtual destructor is unnecessary overhead because every class with a virtual function carries a vtable pointer per instance.\n\nAdding a virtual destructor to a previously non-polymorphic class makes every instance one pointer larger (the vtable pointer) and turns destruction into an indirect call. The cost is small, but it's not free, so don't add `virtual` to a destructor preemptively.\n\n---\n\n# Pitfalls\n\nDestructors look simple, and most of the time they are. Two traps are worth flagging now so they're recognizable when they hit.\n\n### Throwing from a Destructor\n\nThrowing an exception out of a destructor is dangerous. If the destructor is already running because of an in-flight exception (the stack is unwinding), throwing a second exception causes the program to call `std::terminate` and die immediately. There is no way to recover.\n\n\n```cpp\nclass BadOrder {\npublic:\n ~BadOrder() noexcept(false) {\n throw std::runtime_error(\"cleanup failed\"); // dangerous\n }\n};\n```\n\n\nSince C++11, destructors are `noexcept` by default, so any exception that leaves a destructor terminates the program. The fix is to handle errors inside the destructor (catch and log, or set a flag for later) rather than let them escape:\n\n\n```cpp\n#include \n#include \n\nclass Order {\npublic:\n ~Order() {\n try {\n // any cleanup that might fail\n } catch (const std::exception& e) {\n std::cerr << \"cleanup error: \" << e.what() << std::endl;\n // swallow the exception, don't rethrow\n }\n }\n};\n```\n\n\nIn production code, anything that can fail (closing a network connection, flushing a buffer) belongs in a separate `close()` or `commit()` method that callers invoke explicitly. The destructor becomes the last-resort cleanup that has to succeed without raising.\n\n### Calling Virtual Functions from a Destructor\n\nA virtual function call inside a destructor doesn't behave polymorphically. By the time the base class destructor runs, the derived part of the object has already been destroyed, so the virtual dispatch falls back to the base class's version of the function. This is a famous source of confusion when porting code from languages where the rule is different.\n\n\n```cpp\nclass Payment {\npublic:\n virtual ~Payment() { log(); } // does NOT call derived log()\n virtual void log() { /* base */ }\n};\n\nclass CreditCardPayment : public Payment {\npublic:\n void log() override { /* derived */ }\n};\n```\n\n\nThe fix is to not rely on virtual dispatch from a destructor. For cleanup behavior that varies by derived type, the derived destructor is the right place, because by the time the base destructor runs, the derived destructor has already finished. The Polymorphism section returns to this with a full explanation of how virtual calls are dispatched and why the rule is exactly this way.","pageType":"cpp"}

Destructors

Get Premium