Em sábado, 18 de março de 2017, às 10:37:15 PDT, Marc Mutz escreveu: > Ville, > > A word of warning: when it comes to QList, there's a very vocal minority > that claims that either QList works perfectly well or else ain't so bad. > But afaict, there's consensus between the people who actually count (sorry > to be blunt, but Qt is not a democracy, but a meritocracy) that QList as-is > currently was a mistake and needs to go in Qt 6. The only difference in > opinion is how to cushion the fall. > > Lars, Thiago: it would be nice if you could confirm (or deny, in case I > misinterpreted) the above as soon as you can. Otherwise this thread will > derail massively again.
I think we're in agreement. During Qt 5 development, I began the process of rewriting QList so it suffered less from the problems it suffers, but I ran out of time and it was also an impossible task given the requirement to support C++98 at the time (no <type_traits>). The objective was to make QList a hybrid: a real vector with no overhead for types smaller than 32 bytes, a pointer list otherwise. But as time went by, I don't think that hybrid approach is valid. A vector is simply much better. For Qt 6, I'd like QVector and QList to be the same type -- possibly even interchangeable, so that code that began using QVector in Qt 5 will be able to "return" QList. > > In other words, introduce generic code where there wasn't generic code > > before - users writing > > non-generic code calling non-templates that return QLists will need to > > use deduction or a metaprogramming tool. > > No, that is false. You can keep using QList for now everywhere you used it > so far, in non-generic code. Nothing changes for existing types. And for > new types, the compiler will make sure that you don't get away with QList. > We do recommened to use auto to receive QLists to avoid having to port > these code lines manually come Qt 6. I do not consider auto variables > "generic code". I don't agree with the poisoning. See my comment in the QStringView review. I agree we should teach users to port away from QList, but not hat it's such a terrible class that they have to port right now, before using new functionality. > > > 4. Provide QArrayList for code that needs stability of references > > > (stability > > > > > > statically checked in Qt 5, enforced in Qt 6). > > > > It seems that (4) is perfectly safe, whereas (2) and (3) are breaking > > changes; to what extent, I would like to know. Actually, we can get started in (4) right now. This will allow porting now. > (2) is possibly breaking, yes. We should intercept by deprecating > QList::toSet() and re-adding it as a free function. Isn't that simply std::copy? > (3) is breaking nothing for existing code, since it only applies to new > types. New types don't magically show up in your source code. You have to > introduce them yourself. As for existing generic code, it's a > source-incompatibility that is accepted, because it can be fixed by using > auto variables. Or you don't use the new type at all. I mean, we're not > talking about QString here. With very few exceptions, any type we're adding > now will not get widespread use before Qt 6, anyway. One exception > hopefully being QStringView. It's abou the message it brings. Doing that is telling people to port right away, not when they have the time to do it properly. > Indeed, if it was easy, it would have been done long ago. But it's > nonetheless absolutely necessary. Q6String will not fit into a QList > anymore. QVariant and QModelIndex already don't. And given the extensive > use of QVariant in QML/Qt's property system, I don't think anyone can be > happy about the per-element memory allocation in QVariantList. Aye. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
