Virtual Destructor

Feb 7, 2010 at 7:30pm
If I make MyClass's destructor virtual, will it have any impact on anything if my program doesn't use the destructor through polymorphism (in other words, no class will inherit from MyClass, or - if a class MyDerivedClass does inherit, then a MyClass* pointer will never point to a MyDerivedClass object)? In other words, is it a good idea to always make the destructor virtual? Does it have any downsides?
Feb 7, 2010 at 7:43pm
If your class does not have any virtual methods then you don't need to have a virtual destructor.

Calls to virtual functions (including destructor) have a little larger performance cost compared to normal calls due to an additional level of indirection, but in most cases it won't matter.
Feb 7, 2010 at 8:09pm
If you don't have any virtual functions then you will probably have an extra pointer in each object for the vtable, but if you have any virtual functions then it probably won't cost you anything.
Feb 7, 2010 at 8:32pm
As soon as you declare a virtual method or a virtual destructor in a class it is given a vtable
pointer which makes the object 4 bytes (8 on 64-bit machine) bigger.
Feb 8, 2010 at 4:37pm
Does it matter how many virtual functions a class has or there's just one pointer as long as there's at least one virtual function?
Feb 8, 2010 at 6:42pm
It's implementation dependent, although in most cases it will be one pointer which references table containing pointers to all virtual functions.
Feb 9, 2010 at 10:46am
"Most cases" - which compilers use more than one pointer?
Feb 9, 2010 at 12:13pm
I just wanted to say that this is not guaranteed, as the C++ standard does not force any particular implementation.
Feb 9, 2010 at 1:18pm
Is there any benefit to making a function inline as far as speeding up the code, is it something you would notice on a duo core processor? It is my understanding that with inlining, the compiler uses the code from the block in place of the call to the function. I also read somewhere that it is best to keep inlined functions short and simple.
Feb 9, 2010 at 1:55pm
Feb 9, 2010 at 1:59pm
thanks Abramus,
that was actually a good web reference for what I needed, and more. Hey if you can reference it than it saves you the trouble of typing it. I STFW, but I can't always find it, so thank you.
Last edited on Feb 9, 2010 at 2:04pm
Feb 9, 2010 at 4:53pm
I agree with everything the webpage says (that site is pretty good), except that it presents an impractical
solution. In a non-trivial application you could spend an eternity "playing with it" until you find the right
combination of inlines that generates the "best" code (and even then one small change somewhere
else could magically make things worse.)

The approach I tend to take is:

First and foremost, don't fix it if it isn't broken: that means don't think about optimization up front.
Don't optimize prematurely, according to "C++ Coding Standards". Secondly, make one-liners inline.
Constructors - virtually every class I write has a constructor that does everything in an initializer list and
the body is empty. In those cases, I do whatever I feel like at the time. (Whether you find the body of
the constructor in the header or the .cpp file, although inconsistent, isn't really that bad -- Don't sweat
the small stuff, again according to "C++ Coding Standards".

Topic archived. No new replies allowed.