Hi, I had a phone interview recently and was asked some c++ questions. I made a list of questions that I could not answer satisfactorily and started researching them. I could find asnwers to all but one of the question. The question which has stumped is about the downside of using virtual destructor. I was asked "in what case can it be dangerous to use a virtual destructor". And I have not been able to find a suitable answer to this question. One disadvantage of using a virtual destructor is that it creates the overhead of an extra entry in the v-table. But this is a small overhead, and it is in no way dangerous !!

Don't know the exact answer, I think this scenario might be applicable :Suppose class A is base class and class B is derived class. If some pointer member variables of B class (which are not in A) are removed explicitly before calling delete, virtual destructor declatation can cause access violation eg.,class A{}class A1{int j;}class B : public A{A1* m_pA1;virtual~(){delete m_pA1;}}A* pA;pA= new B();delete ((B*)pA)->m_pA1;delete pA; //access violation if destructor of B is virtual. safe it not virtual

I think we're ok in the scenario asd mentioned, but it's always wise to set a pointer to 0 after you delete. Then the 2nd delete (if I'm understanding his example correctly) won't cause the double-delete violation.My answer to the original q would be that some classes should not be used as a base class, and declaring your destructor virtual is inviting others to inherit from it. I think Java lets you express such design intentions with a 'final' keyword or something like that. In C++ it's a little more subtle b/c there's no final keyword -- you simply don't use virtual functions.Also, the 4-byte overhead per object that greenmax mentioned is a legit concern -- especially en masse for small objects.

QuoteOriginally posted by: asdA* pA;pA= new B();delete ((B*)pA)->m_pA1;delete pA; //access violation if destructor of B is virtual. safe it not virtualNo. Since A's destructor is not virtual, deleting the B instance through pA is undefined behavior. In most compilers, B's destructor is not even called, regardless of whether or not it's virtual.Luigi

Luigi, Thanks for the tip! In my experience on Windows/VC++ I did not see any problem if some member variables are not freed, except that memory level consumption by application keeps rising . I agree it is not a good programming habit to leave around stuff in memory, which eventually makes the box and hence the application unstable by consuming large memory. As i understand, you suggest it may be "undefined behavior ' instead of "safe or no access violation error". Can you please advice what other issues can arise if memory alocation is not freed , or some other examples of "undefined behavior" ?Regards

Aside from memory leaks, you can get problems with "external" resources like files, windows, sockets etc.With some external objects it's often best to have both a destructor and a close function.I've found that "close by destruction" looks good, and feels elegant right up unilt 4 AM when you find the bloody bug it caused.

I think the interviewer expected to say something around Athletico's reply, that is: if it is not meant to be a Base, it should not have a virtual destructor. And not only you have the overhead but also the size of your objects will depend on the platform, so if you need to pass these objects to C functions for example you cannot do it in a portable way

QuoteOriginally posted by: AthleticoMy answer to the original q would be that some classes should not be used as a base class, and declaring your destructor virtual is inviting others to inherit from it. I think Java lets you express such design intentions with a 'final' keyword or something like that. In C++ it's a little more subtle b/c there's no final keyword -- you simply don't use virtual functions.How does that help ? The way I see it is that Java prevents you from inheriting from the class by using a Final keyword. But in c++ you can inherit from a class without a virtual destructor. It might be bad programming practice to do so, but the compiler lets you do so. So in the context of the original, it might be a "good" thing to have a virtual destructor so that the careless programmer does not ignore the destructor of the derived class, when using pointer of the same type as base class ??

scott meyers follows the size approach for it being bad and his books are often used by lazy types to glean interview questions

In addition to the extra memory consumption and danger of deleting objects through a base class pointer (whose destructor is not virtual even though the child class's destructor is virtual) metioned earlier, there is the problem that virtual destructors can't be inlined. At first this might appear as performance hit, but it becomes a bigger problem in the case of multiple, dynamically-loaded modules. For example, consider a situation in which a child class in one module is derived from a base class in another module. All instances of the child class must be delete'd before the module containing the base class can be unloaded, or else the child class destructor jumps into the base class destructor which is no longer there. This makes otherwise simple design patterns (like Singleton on the child class) extremely hard to implement, as the timing of the singleton destruction must be carefully choreographed.

QuoteOriginally posted by: greenmaxQuoteOriginally posted by: AthleticoMy answer to the original q would be that some classes should not be used as a base class, and declaring your destructor virtual is inviting others to inherit from it. I think Java lets you express such design intentions with a 'final' keyword or something like that. In C++ it's a little more subtle b/c there's no final keyword -- you simply don't use virtual functions.How does that help ? The way I see it is that Java prevents you from inheriting from the class by using a Final keyword. But in c++ you can inherit from a class without a virtual destructor. It might be bad programming practice to do so, but the compiler lets you do so. So in the context of the original, it might be a "good" thing to have a virtual destructor so that the careless programmer does not ignore the destructor of the derived class, when using pointer of the same type as base class ??I understand what you're saying; it's difficult to know what sort of answer the interviewer was looking for. Was C++ object-oriented design philosophy addressed in the interview? Or was it more about nitty-gritty systems programming questions & runtime issues (memory consumption)? 'Dangerous' is a loaded word, but to me it just means 'don't do it or else' (i.e. bad programming practice as you say). For what it's worth, if it were me interviewing I would have accepted your size answer with full credit.Either derived classes should be able to delete their objects polymorphically (thru a pointer to your base class), or they shouldn't. If polymorphic deletion is allowed, then your destructor must be virtual (and public). Otherwise, it should be non-public and non-virtual to get the compiler to help you prevent bugs. Policy classes are a good example of a base class that is not intended to be used polymorphically - their destructors should be protected and non-virtual.