[Interest] move methods in QList

[Elvis Stansvik]

2017-10-11 21:08 GMT+02:00 Thiago Macieira <thiago.macieira at 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest