Virtual Destructor
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?
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.
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.
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.
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.
pointer which makes the object 4 bytes (8 on 64-bit machine) bigger.
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?
It's implementation dependent, although in most cases it will be one pointer which references table containing pointers to all virtual functions.
I just wanted to say that this is not guaranteed, as the C++ standard does not force any particular implementation.
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.
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.
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
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".
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.