[Development] Are SiCs through #include cleanups considered acceptable?

[Marc Mutz]

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 <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts