Jonathan Franklin wrote:
For example, GCC has a
warning about a derived class whose base doesn't have a virtual dtor. It's actually *impossible* (not just inefficient or convoluted) to implement is_polymorphic without generating that warning.
Interesting. I'm obviously flaunting my ignorance, but I didn't realize that inheriting from a class sans virtual dtor was ever a Good Thing. I'll have to read up on the issues WRT is_polymorphic.
I find inheriting without virtual functions quite useful. The main reason for the virtual destructor rule goes back to Scott Meyers Effective C++. He points out that if you have Base <-- Derived and you call delete Base* the destructor of Derived is not called. In general, it's hard to ensure your derived classes won't need the destructor called and hence the rule. However, if Derived happens to have a trivial/empty destructor then, really there's no reason to call it. As a practical example, my super string 'experiment' uses this technique for interface compatibility with std::string. In one incarnation super_string inherits from std::string, which doesn't have a virtual destructor. Since super_string only adds functions to the type, has no state, and a trivial destructor I don't care that it's not called. So, I have an extended type with functions useful to me, it's backward compatible with the existing type, and no virtual table/destructor is needed. http://www.crystalclearsoftware.com/libraries/super_string/index.html Jeff