TITLE: the cost of inlining con/destructors (Newsgroups: comp.lang.c++.moderated, 6 Jan 97) ZIMMERMAN: Jordan Zimmerman >Do I need to add a virtual destructor to mixin-style classes (i.e. >abstract classes meant to be multiply inherited from)? CLAMAGE: Rule of thumb: Any class that you intend to derive from should have a virtual destructor. Otherwise you risk undefined behavior if you delete an object via a pointer to such a base class. In particular, if a class has virtual functions, it should have a virtual destructor. ZIMMERMAN: >Assuming that the answer is yes, is it OK to make the destructor an empty >inline. It's my understanding that it's a bad idea to make virtual >functions inline (re: More Effective C++, et al). Does this apply to an >empty virtual destructor? CLAMAGE: It isn't necessarily wrong to declare a virtual function (including destructors) inline, assuming it makes sense for the function to be an inline function. Usually it will not be generated inline, except in those cases where the compiler can determine that no virtual call is needed. When the function is invoked via a pointer or reference, the compiler must call a closed subroutine via a pointer, so the "inline" has no benefits in that case. Caveat 1: Although the language definition now says explicitly that all member functions have external linkage, meaning that only one copy exists in the entire program, you cannot depend on current compilers always getting that right in cases where it makes a difference. (Scott Meyers I believe was referring to this situation.) Caveat 2: Constructors and destructors can require a lot of hidden (compiler-generated) code. In general they must set up virtual tables, and construct/destroy base classes and member data. In such cases you usually don't want to make them inline -- every call can result in a lot of code at the call site**. In your example, an empty destructor of a class with no base classes, you won't run into that problem.