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é _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
