On Monday 13 April 2015 09:05:06 André Somers wrote: > Marc Mutz schreef op 11-4-2015 om 14:33: > > On Friday 10 April 2015 14:06:18 André Somers wrote: > >> Marc Mutz schreef op 10-4-2015 om 13:29: > > [...] > > > >>> For one, you're not supoosed to inherit from value classes. For > >>> another... Oh, I think that's enough reasons :) > >> > >> That a religious argument instead of a technical one. > > > > Avoiding undefined behaviour isn't "religious". It's deeply technical. > > See any C++ text book for why. > > Are you saying that Qt was (and still is) sporting classes that exhibit > UB? Really? > > I guess what you mean with "you're not supoosed to inherit from value > classes" is that you should not inherit from classes that don't have a > virtual destructor, right?
Correct. > It was my understanding that it is fine to do > so, as long as you don't add any member variables. What if the derived class' dtor releases some resource that's not explicitly managed in the base class? E.g. a widget could save state to settings. In most implementations, what actually happens is that the derived part of the destructor isn't called when the object is deleted through a pointer to the base class. But the standard says it's UB (N3797 [expr.delete]/3). Nothing mentioned about adding member variables or not. And the danger in _any_ UB these days is that compiler writers are getting more and more aggressive in exploiting the fact that UB cannot happen in a correct program, and optimize out code paths that exhibit UB. > "Any C++ textbook" > doesn't explain what's wrong with that, I don't know about Stroustrup's book, but Effective C++ has an item about it (at least -Weffc++ warns about the construct), C++ Coding Standards has one, and Exceptional C++ coined the current guideline: "a base class dtor should be public and virtual or else protected and non-virtual". Thinking in C++, the book I learned C++ from, at least mentions that it may cause memory leaks. It doesn't say it's UB, but I think it's a pre-standard book if it won an award in 1996. > but if you'd like to enlighten > me (and perhaps others): please do so. You've put me on another > interesting track I learned a lot from before (again: thank you for > that!), so why not a second time... HTH, Marc -- Marc Mutz <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
