virtual-destructor

/*Child is inherited from Parent*/ class Parent { public: Parent () //Constructor { cout << "\n Parent constructor called\n" << endl; } protected: ~Parent() //Dtor { cout << "\n Parent destructor called\n" << endl; } }; class Child : public Parent { public: Child () //Ctor { cout << "\nChild constructor called\n" << endl; } ~Child() //dtor { cout << "\nChild destructor called\n" << endl; } }; int main () { Parent * p2 = new Child; delete p2; return 0; } If I make Parent 's destructor virtual, then I obtain an error, so what is the purpose of making a protected destructor virtual? Just to give

I want to inherit from std::map , but as far as I know std::map hasn't any virtual destructor. Is it therefore possible to call std::map 's destructor explicitly in my destructor to ensure proper object destruction? The destructor does get called, even if it's not virtual, but that's not the issue. You get undefined behavior if you attempt to delete an object of your type through a pointer to a std::map . Use composition instead of inheritance, std containers are not meant to be inherited, and you shouldn't. I'm assuming you want to extend the functionality of std::map (say you want to find

Why doesn't C++ make destructors virtual by default for classes that have at least one other virtual function? In this case adding a virtual destructor costs me nothing, and not having one is (almost?) always a bug. Will C++0x address this? Kerrek SB You don't pay for what you don't need. If you never delete through base pointer, you may not want the overhead of the indirected destructor call. Perhaps you were thinking that the mere existence of the vtable is the only overhead. But each individual function dispatch has to be considered, too, and if I want to make my destructor call dispatch

As I know, any class that is designated to have subclasses should be declared with virtual destructor, so class instances can be destroyed properly when accessing them through pointers. But why it's even possible to declare such class with non-virtual destructor? I believe compiler can decide when to use virtual destructors. So, is it a C++ design oversight, or am I missing something? Are there any specific reasons to use non-virtual destructors? Yes, there are. Mainly, it boils down to performance. A virtual function cannot be inlined, instead you must first determined the correct function to

class Base{}; class D1:virtual public Base{}; class D2:virtual public Base{}; class DD:public D1,public D2{}; int main(){ Base *pBase=new DD; delete pBase; } This leads to crash, but I modify as below: class Base{ public: virtual ~Base(){}; }; class D1:virtual public Base{ public: virtual ~D1(){} }; class D2:virtual public Base{ public: virtual ~D2(){} }; class DD:public D1,public D2{ }; Then, it passes, but the default destructor should be the virtual dummy function, isn't it? From the C++11 specification (ISO/IEC 14882:2011(E)), section 12.4 Destructors [class.dtor]: Sub-section 4: If a

In this answer , Ryan directly calls the virtual destructor. I've tested the code in VS2010, and it correctly calls all destructors (tested with logging statements). Is it actually valid to do so? What are the problems, flaws or even the good points of such an approach? I can only think of it as a way to really force a reset of the actual type, even if they don't override a virtual reset function, since they atleast have to clean up in their destructors. Also, eactly what kind of side-effects does a call to the destructor bring? Is it undefined behaviour to use the object after such a

I have struct IMyInterface { virtual method1() = 0; virtual method2() = 0; }; GCC insists that I have struct IMyInterface { virtual method1() = 0; virtual method2() = 0; virtual ~IMyInterface(){}; }; I dont see why. A pure interface is all about the interface (duh). The destructor is part of the internal implementation details of a concrete implementer of the interface; it does not form part of the interface. I understand the whole slicing issue (or at least I think I do) So my question is - is GCC right to insist on it and if so why? According to the C++ spec, yes. You need to declare the

In a freestanding context (no standard libraries, e.g. in operating system development) using g++ the following phenomenon occurs: class Base { public: virtual ~Base() {} }; class Derived : public Base { public: ~Derived() {} }; int main() { Derived d; } When linking it states something like this: undefined reference to operator delete(void*) Which clearly means that g++ is generating calls to delete operator even though there are zero dynamic memory allocations. This doesn't happen if destructor isn't virtual. I suspect this has to do with the generated vtable for the class but I'm not