David Abrahams wrote:
on Sat May 05 2007, Jeff Garland <jeff-AT-crystalclearsoftware.com> wrote:
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
As long as you don't tell people a super_string IS-A std::string, you're arguably okay... though even then, they'll still probably end up invoking UB unintentionally.
I actually don't think it's too important what I say. Most code won't invoke the UB, but even if the user strays into the UB it's harmless. Technically there is a risk that some future compiler might change the UB into bad behavior, but that risk seems small. All this is making me wonder if there isn't some reason that this has to be UB since all the compilers have the same solution... Jeff