|
Boost : |
From: Jeff Garland (jeff_at_[hidden])
Date: 2007-05-05 12:10:12
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk