Why does a polymorphic base need a virtual destructor?
Asked almost universally, and the weak answer is 'otherwise it leaks'. Leaking is a symptom. The question is what the standard says about the construct itself.
Exam
Answer these to pass this module.
Start here rather than at the reading. Whatever you miss tells you which part of Learn you actually need — and anything you get right is a part you can skip.
You delete a Derived object through a Base* whose destructor is not virtual. What does the standard say?
Why not just give every class a virtual destructor?
You have a base class nobody should ever delete through. What is the cleanest way to say so?
Explain mode
Why does a polymorphic base need a virtual destructor?
Write the two-line program that triggers it, then explain what the compiler is entitled to do.
Your own words, two or three sentences, nothing looked up. The rubric unlocks once you submit.
Graded against a set rubric. Three a day on a free account. Need more? Ask on our Facebook page — it's free.
Learn
Static versus dynamic type, how the destructor is dispatched, what delete through a base pointer actually does, and the rule of thumb about a base class being either polymorphic-with-virtual-destructor or not-deleted-through-base at all.
Ask an AI to teach you this
I'm preparing for a quant developer interview on "Why does a polymorphic base need a virtual destructor?" Concepts I need to own: static versus dynamic type, how the destructor is dispatched, what delete through a base pointer actually does, and the rule of thumb about a base class being either polymorphic-with-virtual-destructor or not-deleted-through-base at all. Run this as interview practice, not a lecture. One concept at a time. Wait for my answer before moving on. Per concept: 1. Teach it. Lead with the one-line core claim, then a few short paragraphs. Assume I write C++ but have never had this explained properly. No jargon without defining it. 2. "The 60-second version" — what a strong candidate would SAY out loud. First person, spoken register, no bullets, no headers. That's what I'm rehearsing. 3. Ask me one question that exposes whether I only think I understood it. When I answer, reply in exactly this shape: Verdict: correct / partly correct / wrong — one line on what's wrong. What you missed: only if something's missing. 2-3 sentences. Vocabulary: only if I used a wrong or vague term. Give the right one. Example answer: the model spoken answer, 30 seconds max, first person. More info: define any term I probably don't know, one line each. Follow-up probe: the one question an interviewer asks someone who gave that model answer. Skip any section that doesn't apply. Don't pad. If I'm wrong, say wrong — don't soften it. Do not write my implementation for me. If I ask, refuse and ask what I'd try instead — I need to defend this code with the editor closed.
Do
Ship
Practice with AI
Use these to make the AI your examiner, not your author. If the AI wrote the code, this node doesn't count — you can't defend a design you didn't make.
- P8 — grade my explanation against the rubric, and name what I left out
- P2 — adversarial test suite (try to break my implementation)