0

This question looks like the discussion in Virtual destructor: is it required when not dynamically allocated memory?

In an exam question, I have been asked: - What should any base class that maintain pointers to dynamically allocated memory define?

I answered: - A copy constructor and an assignment operator (to make sure NOT only pointers are copied... c.f. deep copy), and a destructor (to free allocated memory)

They said this is not correct because this base class should also define a virtual destructor instead of the plain destructor. Why?

Community
  • 1
  • 1
Djibril NDIAYE
  • 216
  • 2
  • 9
  • 4
    You should ask your examiner, not us. She is the one who asserts that you that you need a virtual destructor. – Robᵩ Sep 07 '12 at 14:34
  • 6
    You are perfectly entitled to an explanation from your examiner as to why and this should be your first action. – mathematician1975 Sep 07 '12 at 14:36
  • 2
    The bit about containing dynamically allocated resources is a bit of a red herring. The key thing is "base class", which implies inheritance, and hence the possibility for deleting a derived class via a base-class type pointer which is where you need to worry about virtual destructors. – Rook Sep 07 '12 at 14:37

6 Answers6

6

If your class is intended to be used polymorphically, you'll likely have pointers to the base class that point to derived objects.

Deleting a derived object through a pointer to a base class with no virtual destructor causes undefined behavior. That's probably her reasoning.

5.3.5

3) In the first alternative (delete object ), if the static type of the operand is different from its dynamic type, the static type shall be a base class of the operand’s dynamic type and the static type shall have a virtual destructor or the behavior is undefined. [...]

Luchian Grigore
  • 253,575
  • 64
  • 457
  • 625
5

Your base class needs a virtual destructor if objects of derived classes are intended to be destroyed via a base-class pointer, like so

Base *pointer_to_base_class = new Derived;
delete pointer_to_base_class;

From your question, it is unclear whether this is the case. Perhaps another part of the question (or a previous question) made clear that such polymorphic destruction was intended. Or, perhaps you were taught during the class to always anticipate such use as a best practice.

Robᵩ
  • 163,533
  • 20
  • 239
  • 308
  • 1
    +1 for also clarifying that nothing in that particular question hints at the need for virtual destruction. –  Sep 07 '12 at 14:41
  • It isn't too great a leap of logic to say that if you are working with a class hierarchy then this sort of polymorphism _could_ occur, and therefore designing defensively by using virtual destructors _should_be done. At least, in any non-trivial application. – Rook Sep 07 '12 at 14:53
5

They are not 100% correct. Virtual destructor is a must if

  1. class hierarchy used with dynamic polymorphism AND
  2. derived objects are destroyed via pointer to base.

Otherwise non-virtual destructor is OK. But in most cases even if only #1 is intended it's a good style to make destructor virtual regardless of #2.

Rost
  • 8,779
  • 28
  • 50
1

Within the standard, most inheritance hierarchies have a virtual destructor at their base; however, sub_match is defined to public inherit from std::pair<BidirectionalIterator, BidirectionalIterator> and as such it could own dynamically allocated memory. In a related area, match_results is not required to but usually implemented to public inherit from std::vector<...> which definitely allocates memory.

Your examiner is not entirely incorrect, but the focus on dynamically allocated memory is a red herring and betrays a worrying ignorance of the standard; while in most implementations deleting a derived type by a pointer to base type without virtual destructor will result in destructing a sliced object, per the standard it is undefined behaviour.

ecatmur
  • 152,476
  • 27
  • 293
  • 366
  • yes, maybe with the new c++ rtti usage (dynamic_cast, typeid), we can do more stuff with templates and "intermediate code generation"... in this case, you are right.. should always define desctructor as virtual, as u don't know what/how the added code will be using you're class. Maybe I'll be studying how to adopt defensive programming by using the new keywords (non copyables, final, delete, etc...) – Djibril NDIAYE Sep 10 '12 at 17:59
0

Adding to the other answers: You could also envisage a situation where you do want a common base class, but you don't have any actual interface functions for it. But if you want RTTI and dynamic cast support, you need a virtual function in your class. A destructor can be just that function.

For example, imagine you're a recovering Java programmer and insist that everything is an Object. You might start your first C++ program like so:

class Object
{
public:
   virtual ~Object() { }
};

Now Object can indeed serve as the ultimate polymorphic base class of each of your classes.

If you also think that Object should be abstract, you can even make the destructor pure-virtual:

class Object { public: virtual ~Object() = 0; }; Object::~Object() { }

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • 2
    Of course, you shouldn't actually do that, so it's kind of a silly reason. –  Sep 07 '12 at 14:42
  • Consider my comment an explanatory annotation :) I assume that you know this better than I do. –  Sep 07 '12 at 14:44
  • When you are not sure, you declare it protected. So if you really need it, MS Visual Studio Compiler 2010 will tell u. – Djibril NDIAYE Sep 10 '12 at 00:19
0

To follow up with all good answers here this is good practice to declare a virtual destructor to ensure a proper clean-up when a class is supposed to be subclassed to form a hierarchy and you want to delete the derived object through a pointer to it. The C++ standard is clear on this:

when you want to delete a derived class object through a base class pointer and the destructor of the base class is not virtual and the result is undefined

By undefined behavior you could think of memory leaks for example if your derived class allocate some dynamic memories and you try to delete it later on through this base class. Your teacher was probably thinking of this scenario.

tiguero
  • 11,477
  • 5
  • 43
  • 61
  • 2: I have no picture about what you are saying 1: This is an axem and I have not to answer any teacher 0: I see I give no reference but 10 years I look for this answee.. – Djibril NDIAYE Sep 10 '12 at 01:31
  • It's not about "proper cleanup" - which implies that if the user has derived classes that can be `delete`d through base pointers, is too lazy to write a virtual destructor, and doesn't have or care about memory leaks - such a `delete` is somehow OK as they have nothing to "cleanup" or aren't fazed by small leaks. It's _not_ OK: it's pure UB - so if that `delete` occurs, their entire program becomes a time bomb; regardless of whether it ends up leaking, it can't be trusted anymore. UB has to be avoided, at all costs. – underscore_d Sep 27 '16 at 20:22