2017-10-11 21:08 GMT+02:00 Thiago Macieira <thiago.macie...@intel.com>: > On terça-feira, 10 de outubro de 2017 14:31:05 PDT Christian Gagneraud wrote: >> It's full of interesting information, like: >> - Don't use Qt container, unless you have to >> - Do not use QList, prefer QVector. > > And I complained to him right afterwards. > > The advice should be: > - do use the Qt Containers, unless you can't > - use QVector, not QList, unless you need QList'svery specific behaviour > (if you don't know what that is, you don't need it)
Sorry for jumping in here. I've recently been reading back on some of the threads on the disadvantages of QList, especially the thread right before the time when the QList docs were updated to no longer suggest it as the "go-to" Qt container. I've also looked through Guiseppes slides, and reading other discussions here and there. And I'm still confused. I'd like to do the right thing, but right now I'm unsure if that is: - Use std containers as much as possible (i.e. always except if I need to interface with Qt APIs) - Use Qt containers, but pick QVector over QList whenever possible (your suggestion) - Use QList, it's not that bad after all, and has good worst-time for many operations There seem to be differing opinions even among Qt heavyweights on how strongly QList use should be discouraged, and even on how strongly (if at all) Qt container use should be discouraged. I know the difference between QVector and QList, and the quirks of QList (not least of all because it's been discussed a lot), so I guess the best thing I can do is form an opinion of my own, and stick to that. But.. one thing I don't like about the advices like "Use X ... except if you possibly intend to interface with the Qt API" (where X is QVector, or maybe std::vector depending on your stance) is that sometimes you simply don't know that up-front. Also, it gives a sort of Frankenstein appearance to the code, where it's not clear to a casual reader why one type of container was picked over the other. Could others chime in here. If you were to start a project today, what focus would you have wrt to containers? Would you do your utmost to stay with std containers? Strive to use Qt containers, but avoid QList as much as possible? Or even not be afraid of QList use at all, for the convenience of being able to pass it to some Qt API later on? Another thing for you Qt devs: Qt's APIs are littered with QList. Guiseppe mention in his slides that it's out of the question to change that for Qt 6, because it would be such a big API break. But, when should such a change be made, if not during a major version bump? There's nothing more major than that. The only more careful approach I can think of is deprecation over a full major cycle, only to be changed in the next. Or are we going to live with a Qt API that interfaces using a discouraged container forever? Elvis > > Out of the discussion at the Qt Contributor Summit, we concluded we will most > likely keep our containers in Qt 6 and they'll continue to be implicitly > shared. We may provide a non-implicitly-shared alternative (with all the Qt > look and feel, possibly even exception-safe for QVector, QMap and QHash). > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
