Should all destructors be virtual?

Started by
11 comments, last by SiCrane 17 years, 8 months ago
Shouldnt all destructors be declared virtual because of the possibility that an inherited object will be destructed through a base class pointer? This seems like a good precaution that would future-proof/idiot-proof your classes. Does this sound like a good practice? Do you guys do this?
Advertisement
If a class is meant to be subclassed, then you must declare the destructor as virtual, or your class won't compile. The key here is deciding what is and what isn't meant to be subclassed.
http://blog.protonovus.com/
http://blogs.msdn.com/oldnewthing/archive/2004/05/07/127826.aspx
Assuming C++.

No, many concrete classes shouldn't be inherited from. Just look at the SC++L, here many classes lack a virtual destructor because they shouldn't be inherited from. For more information (also about virtual functions in general) I suggest that you read this.
Quote:Original post by swordfish
If a class is meant to be subclassed, then you must declare the destructor as virtual, or your class won't compile. The key here is deciding what is and what isn't meant to be subclassed.


No, the problem is that the derived classes will compile, but the wrong destructor will be called if the class is deleted through a pointer to the base class.
FAQ [20.7] When should my destructor be virtual? (www.parashift.com)

That FAQ is gold dust IMHO. Keep it for future reference.
Quote:Original post by SiCrane
Quote:Original post by swordfish
If a class is meant to be subclassed, then you must declare the destructor as virtual, or your class won't compile. The key here is deciding what is and what isn't meant to be subclassed.


No, the problem is that the derived classes will compile, but the wrong destructor will be called if the class is deleted through a pointer to the base class.


I know of compilers that actually won't let you inherit from a base class that doesn't have a virtual destructor but I assume this is an extension and not part of the standard.

Slightly more on topic, C++ maintains the "If you don't want it, you don't pay for it" approach and declaring a destructor virtual for a concrete type that is not meant to be inherited from would add the unecessary overhead of a virtual table pointer to each instance of the class.

I quite like the extension described above though. I guess it could not become part of the standard though since there could be instances where you don't want it. Pretty rare though.
Quote:Original post by EasilyConfused
I know of compilers that actually won't let you inherit from a base class that doesn't have a virtual destructor but I assume this is an extension and not part of the standard.

That's not an extension; that's just plain broken. Inheriting from a class with a non-virtual destructor can be useful in instances such as policy classes with a protected destructor.
Quote:Original post by SiCrane
Quote:Original post by EasilyConfused
I know of compilers that actually won't let you inherit from a base class that doesn't have a virtual destructor but I assume this is an extension and not part of the standard.

That's not an extension; that's just plain broken. Inheriting from a class with a non-virtual destructor can be useful in instances such as policy classes with a protected destructor.


Protected deconstructor? What does that do?

Doesnt that mean an cant be deleted/deallocated? When it goes out of scope or is explicitly delete'd wouldnt there be a runtime error or something?
On -Wall, gcc warns you if you make a class with a virtual function and a non-virtual destructor.

Seems a reasonable comprimise to me.

This topic is closed to new replies.

Advertisement