{"title":"Pure Virtual Functions","description":null,"content":"A regular `virtual` function says \"derived classes may override me.\" A pure virtual function says \"derived classes must override me, and the base class cannot be instantiated until they do.\" That single change turns a class from a thing you can create into a contract that other classes have to fulfill. This lesson covers the syntax, what changes about the class once you add the `= 0` marker, and the edge cases.\n\n---\n\n# The `= 0` Syntax\n\nA pure virtual function is declared by writing `= 0` after the parameter list of a virtual member function.\n\n\n```cpp\n#include \n#include \n\nclass Notification {\npublic:\n virtual void send(const std::string& message) = 0;\n virtual ~Notification() = default;\n};\n```\n\n\nThe `= 0` at the end is called the **pure specifier**. It does not assign zero to anything. It is not setting a function pointer to null. It is a piece of declaration syntax that means \"this function has no default implementation that the class wants to commit to, and any concrete derived class must supply one.\"\n\nThe choice of `= 0` was historical. The committee needed a token that already existed in the grammar and wouldn't break old code. They picked the digit zero because it was unused in that position and was easy to type. Don't read meaning into the value itself. \"The address of this function is zero\" is wrong. \"A marker that completes the declaration\" is right.\n\nA class with at least one pure virtual function is called an **abstract class**. Variables of pointer or reference type to an abstract class can be declared, but an instance cannot be created.\n\n\n```cpp\n#include \n#include \n\nclass Notification {\npublic:\n virtual void send(const std::string& message) = 0;\n virtual ~Notification() = default;\n};\n\nint main() {\n // Notification n; // compile error\n return 0;\n}\n```\n\n\nUncommenting the line produces an error like:\n\n\n```shell\nerror: cannot declare variable 'n' to be of abstract type 'Notification'\nnote: because the following virtual functions are pure within 'Notification':\nnote: 'virtual void Notification::send(const std::string&)'\n```\n\n\nThe compiler refuses to create a `Notification` because it doesn't know what `send` should do. The function exists in the type's interface but has no body to call. Constructing such an object would leave a member function in an undefined state, so the language blocks it at compile time.\n\n---\n\n# Concrete Derived Classes Must Override Every Pure Virtual\n\nOnce a class is abstract, the rule is simple. A derived class becomes concrete (creatable) only when every pure virtual function inherited from its bases has a non-pure override in that class or in some ancestor below the one that declared it pure.\n\nIf a derived class overrides every pure virtual, it is concrete. If it misses even one, it is still abstract and cannot be instantiated either.\n\n\n```cpp\n#include \n#include \n\nclass Notification {\npublic:\n virtual void send(const std::string& message) = 0;\n virtual void format(const std::string& message) = 0;\n virtual ~Notification() = default;\n};\n\nclass EmailNotification : public Notification {\npublic:\n void send(const std::string& message) override {\n std::cout << \"Email sent: \" << message << std::endl;\n }\n\n void format(const std::string& message) override {\n std::cout << \"Formatting as HTML: \" << message << std::endl;\n }\n};\n\nint main() {\n EmailNotification email;\n email.format(\"Order shipped\");\n email.send(\"Order shipped\");\n return 0;\n}\n```\n\n\n`EmailNotification` overrides both pure virtuals, so it is concrete and the local variable is fine.\n\nConsider a derived class that only overrides one of the two:\n\n\n```cpp\n#include \n#include \n\nclass Notification {\npublic:\n virtual void send(const std::string& message) = 0;\n virtual void format(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 sent: \" << message << std::endl;\n }\n // format() not overridden\n};\n\nint main() {\n // SmsNotification sms; // compile error: still abstract\n return 0;\n}\n```\n\n\nThe commented line fails to compile with the same \"cannot declare variable to be of abstract type\" message, except this time the unimplemented function is `format`. `SmsNotification` inherits `format` from `Notification`, where it is pure. Since `SmsNotification` doesn't override `format`, it inherits the pure specifier along with the declaration. The compiler treats `SmsNotification` as abstract too, and refuses to construct it.\n\nThis is a common cause of \"I made a class but it says it's abstract.\" The fix is to find the missing override.\n\n\n```mermaid\nflowchart TD\n Base[Notification
send 0
format 0]:::orange --> E[EmailNotification
send overridden
format overridden]:::green\n Base --> S[SmsNotification
send overridden
format MISSING]:::red\n\n E --> EOK[Concrete
can instantiate]:::green\n S --> SBAD[Still abstract
cannot instantiate]:::red\n\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 diagram captures the rule visually. Inheriting from an abstract class isn't enough to become concrete. A class only escapes the \"abstract\" label by supplying a real body for every pure virtual.\n\n---\n\n# Pointers and References to Abstract Classes Are Fine\n\nThe \"cannot instantiate\" rule applies to objects, not to pointers or references. `Notification*` or `Notification&` are perfectly legal, and they are how polymorphic code talks to the abstract base.\n\n\n```cpp\n#include \n#include \n\nclass Notification {\npublic:\n virtual void send(const std::string& message) = 0;\n virtual ~Notification() = default;\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\nclass SmsNotification : public Notification {\npublic:\n void send(const std::string& message) override {\n std::cout << \"SMS: \" << message << std::endl;\n }\n};\n\nvoid notifyCustomer(Notification& channel, const std::string& message) {\n channel.send(message);\n}\n\nint main() {\n EmailNotification email;\n SmsNotification sms;\n\n notifyCustomer(email, \"Your order has shipped\");\n notifyCustomer(sms, \"Your order has shipped\");\n return 0;\n}\n```\n\n\n`notifyCustomer` takes a `Notification&`. The reference is bound to a concrete derived object at the call site. There is never an actual `Notification` instance anywhere in memory. The reference is a way to refer to \"any concrete subclass of `Notification`\" without committing to which one. Virtual dispatch on `channel.send(message)` finds the right `send` based on the actual object behind the reference.\n\nThe same idea works with pointers and with smart pointers:\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 EmailNotification : public Notification {\npublic:\n void send(const std::string& message) override {\n std::cout << \"Email: \" << message << std::endl;\n }\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\nint main() {\n std::vector> channels;\n channels.push_back(std::make_unique());\n channels.push_back(std::make_unique());\n\n for (const auto& channel : channels) {\n channel->send(\"Your refund has been processed\");\n }\n return 0;\n}\n```\n\n\nA `std::vector>` is a legal container of pointers to an abstract type. Each slot owns a concrete subclass, and the loop talks to all of them through the base type. This is what abstract classes are for in practice: writing code against a contract instead of a specific implementation.\n\n---\n\n# A Pure Virtual Function Can Still Have a Body\n\nThe `= 0` says \"every concrete derived class must provide its own override.\" It does not say \"the base class cannot have an implementation.\" A pure virtual function can have a body. The body isn't picked up automatically; derived classes have to opt into it.\n\nThe body is provided outside the class, with the regular member function definition syntax:\n\n\n```cpp\n#include \n#include \n\nclass Notification {\npublic:\n virtual void send(const std::string& message) = 0;\n virtual ~Notification() = default;\n};\n\n// Default body for the pure virtual function.\nvoid Notification::send(const std::string& message) {\n std::cout << \"[log] sending: \" << message << std::endl;\n}\n\nclass EmailNotification : public Notification {\npublic:\n void send(const std::string& message) override {\n Notification::send(message); // chain into the base's logging\n std::cout << \"Email delivered: \" << message << std::endl;\n }\n};\n\nint main() {\n EmailNotification email;\n email.send(\"Order confirmed\");\n return 0;\n}\n```\n\n\n`Notification::send` is declared pure (`= 0`) and also defined out of line. `EmailNotification` overrides `send` so that it is concrete, and the override explicitly calls `Notification::send(message)` to reuse the base behavior before adding its own. The qualified call is the only way to reach the base body, because virtual dispatch through the type itself would just call back into the override.\n\nThis pattern fits when the base has some shared logic that every subclass will probably want, but no subclass would be correct using only that logic. The pure specifier forces every concrete subclass to think about it (\"`send` must be written, even if it only forwards to the base\"), while the body offers a shortcut for the common case.\n\nA small caveat. The body for a pure virtual function is defined out of line in most code, like the example above. C++ allows defining it inline inside the class with `virtual void send(...) = 0 { ... }` on some compilers, but this is non-portable. Stick to the out-of-line form.\n\n---\n\n# The Pure Virtual Destructor\n\nA destructor can be pure virtual too. This is a special case because of how destructor calls work: when a derived object is destroyed, the derived destructor runs first, then control automatically passes to the base destructor, regardless of whether the base is virtual, pure, or neither. The base destructor body must exist, because the chain will call it.\n\nThat leads to syntax that looks contradictory at first.\n\n\n```cpp\n#include \n#include \n\nclass Notification {\npublic:\n virtual ~Notification() = 0; // pure virtual destructor\n};\n\n// Body is required, even though the destructor is pure.\nNotification::~Notification() {\n std::cout << \"[Notification cleanup]\" << std::endl;\n}\n\nclass EmailNotification : public Notification {\npublic:\n ~EmailNotification() override {\n std::cout << \"[EmailNotification cleanup]\" << std::endl;\n }\n};\n\nint main() {\n Notification* n = new EmailNotification();\n delete n;\n return 0;\n}\n```\n\n\nThe destructor is declared with `= 0` inside the class, and then defined right below with `Notification::~Notification() { ... }`. Without the body, the linker would complain. Forgetting the body produces this error:\n\n\n```shell\nundefined reference to `Notification::~Notification()'\n```\n\n\nThe error happens at link time, not compile time, because the destructor declaration is fine. The trouble shows up when `EmailNotification`'s destructor tries to chain into the base's destructor and can't find it.\n\nWhy use a pure virtual destructor? The pattern fits when a class should be abstract but there's no other natural pure virtual function to put there. The class has a few virtuals with sensible default bodies, no abstract operations of its own, and direct instantiation should still be forbidden. Marking the destructor `= 0` is the lightest way to make the class abstract. The destructor still runs as expected because the body is supplied.\n\n\n```mermaid\nflowchart LR\n Decl[Declaration
virtual ~Notification 0]:::orange --> Abstract[Class is abstract
cannot instantiate]:::cyan\n Decl --> Body[Body still required
defined out of class]:::green\n Body --> Chain[Derived dtor chains in
finds the body at link time]:::green\n\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe diagram captures the split: the `= 0` makes the class abstract, but the body is still mandatory because the destructor chain will call it.\n\n---\n\n# What Happens If a Pure Virtual Is Called\n\nMost pure virtual functions never get called through a base. Concrete subclasses provide their own bodies, and virtual dispatch finds the override. The pure version exists as a slot in the vtable that says \"concrete subclasses fill me in.\"\n\nBut the slot has to point somewhere. Compilers (Itanium ABI, used by g++ and clang++) fill it with a sentinel function called `__cxa_pure_virtual`. If that function ever gets called, it prints a message and aborts the program.\n\n\n```shell\npure virtual method called\nterminate called without an active exception\nAborted\n```\n\n\nWhen could a pure virtual call actually happen? It shouldn't, because the language won't let you instantiate an abstract class directly. But there is one corner: during the construction or destruction of an abstract base, the object's vtable temporarily points at the base's own vtable, not the derived one. Any virtual call made from inside the base constructor or destructor body resolves to the base's version.\n\nFor a regular virtual that has a body, that's a \"the override won't be called yet\" surprise. For a pure virtual with no body in the base, that same surprise becomes a runtime crash, because the call lands on `__cxa_pure_virtual`.\n\n\n```cpp\n#include \n#include \n\nclass Notification {\npublic:\n Notification() {\n // BUG: send is pure virtual and has no body here.\n // During construction, the call resolves to the base slot.\n send(\"[constructor message]\");\n }\n\n virtual void send(const std::string& message) = 0;\n virtual ~Notification() = default;\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 EmailNotification email; // crashes at construction\n return 0;\n}\n```\n\n\nRunning this aborts with the \"pure virtual method called\" message above. The reason matches that lesson's discussion of calling virtual functions from constructors. Inside `Notification::Notification`, the object is still under construction as a `Notification`. The vptr points at `Notification`'s vtable, where `send` is the pure slot. The call goes through that slot, which is `__cxa_pure_virtual`, and the runtime terminates the program.\n\nThe fix is the same: don't call virtual functions from constructors or destructors of a base class. With a pure virtual, doing so guarantees a crash. With a regular virtual, it works but ignores derived overrides. Either way, run derived behavior from a separate `init()` call that runs after construction finishes.\n\nA pure virtual function uses a vtable slot like any other virtual function. There's no runtime overhead difference between calling a pure virtual override and a regular virtual override after the object is constructed. The only behavioral wrinkle is the sentinel slot's contents while the object is being built.\n\n---\n\n# Abstract Classes as Interface-Like Types\n\nA common shape in modern C++ is an abstract class that has no data, only pure virtual functions, plus a virtual destructor. That shape is C++'s closest thing to what some other languages call an interface. It is a class, structurally, but it does the same job: it defines a set of operations that subclasses must implement, without supplying any state or behavior of its own.\n\n\n```cpp\n#include \n#include \n#include \n\nclass PaymentMethod {\npublic:\n virtual void charge(double amount) = 0;\n virtual ~PaymentMethod() = default;\n};\n\nclass CreditCard : public PaymentMethod {\npublic:\n void charge(double amount) override {\n std::cout << \"Charged $\" << amount << \" to credit card\" << std::endl;\n }\n};\n\nclass GiftCard : public PaymentMethod {\npublic:\n void charge(double amount) override {\n std::cout << \"Charged $\" << amount << \" to gift card\" << std::endl;\n }\n};\n\nvoid checkout(PaymentMethod& method, double total) {\n method.charge(total);\n}\n\nint main() {\n CreditCard card;\n GiftCard gift;\n checkout(card, 49.99);\n checkout(gift, 25.00);\n return 0;\n}\n```\n\n\n`PaymentMethod` has nothing in it except a pure virtual `charge` and a virtual destructor. There are no fields, no concrete logic, no helper methods. Subclasses implement `charge` however they need. `checkout` works against `PaymentMethod&` and doesn't care which concrete subclass it gets. New payment methods can be added later without touching `checkout`.\n\nThis barely scratches the surface of the topic. The Abstraction section covers the design discussion properly, including when \"interface-like\" classes fit best and how they relate to dependency inversion. For now, the takeaway is that a pure-virtual-only class is a legal, common, and useful shape in C++ code.","pageType":"cpp"}

Pure Virtual Functions

Get Premium