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

[André Somers]

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? It was my understanding that it is fine to do 
so, as long as you don't add any member variables. "Any C++ textbook" 
doesn't explain what's wrong with that, 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...
>> It was meant as a serious question.
> And this was a serious answer. :)
>
>> It looks to me like the chosen
>> alternative is more complex than what was there before,
> That's the bane of C++ library developers. They get to eat the mud so users
> can have nice shiny interfaces. In this case, after the change (and its
> completion) there's only one class that deals with lists of strings and not
> two. Easier. The user cannot accidentally invoke UB because there's only one
> class he needs to deal with. Safer. No extra code necessary for generic
> programming, as QList<QString> is fully featured. Easier. Less useless
> conversions between QList<QString> and QStringList. More performant.
>
> For us, a major advantage is that we can equip QVector<QString> with the same
> extended API as QStringList, easily. That'd just be the next step.
>
I get all of these except for the UB/Safer argument. And yes, they are 
good arguments to do this, Olivier already provided a convincing use 
case. I still don't like that the documentation is now pretending that 
QList<QByteArray> is still a class though: as there are good arguments 
to introduce this change, why lie to the user about it?

André