Thread: problem with classes and pointers

I believe the rule is that if you have a virtual function, the destructor should be virtual since it implies you are going to use polymorphism. Inheritance does not necessarily mean you are going to use polymorphism, thus virtual destructors are usually only an overhead.

Well, I dunno exactly what virtual means, but it doesn't change anything serious, if placed wrong, right?

Best read up about inheritance, polymorphism and virtual functions, as well as abstract base classes (pure virtual functions).
Not using virtual correct can mean overhead and headaches.

Also, while deriving classes will "inherit" the virtual status of functions (including destructors), it is good practice, methinks, to actually mark them as virtual anyway, because it may not be obvious they are virtual unless you take a look at the base class and it doesn't hurt to put virtual in there anyway.

Yes, it will.

Despite what has been offered, you only need a virtual destructor if you are going to destroy an object polymorphically. (If you religiously use good smart pointers, it is really a non-issue, but still, rather safe than sorry.) However, if you get this wrong, you destroy the universe. Consequently, if you already have one virtual method, marking the destructor as virtual will save you a headache and probably cost you only a little overhead--probably only measurable in hundreds of thousands of iterations or tens of bytes.

By the by, it is always the "handle" class that needs a virtual destructor. (Where the "handle" class is whatever type you will store a pointer to for the sake of polymorphic destruction.) The destructor for classes that inherit from the "handle" class do not need to be marked 'virtual'.

Soma