[Development] QList for Qt 6
Matthew Woehlke
mwoehlke.floss at gmail.com
Thu Jun 13 00:14:16 CEST 2019
(Sorry for not chiming in earlier, this was hidden waaaay at the top of
my spool where I didn't notice there were unread messages.)
On 22/05/2019 09.49, Lars Knoll wrote:
> Let’s conclude the topic of QList. I do see the concern about silent
> source breakages. Here’s what we’ll (I’ll) do then for Qt 6:
>
> 1. Rename QList to QArrayList and make QList an alias to QArrayList
+lots. I have (grudgingly) been slowly moving toward using QVector more,
but I still think there are legitimate cases when it makes sense to
avoid copies-during-resizing. And, of course, there are times when one
needs reference stability. I don't want to lose that container.
It would be helpful to have a QArrayList that *always* uses indirect
storage, and to have a clazy check for use of QArrayList<T> where
QVector<T> is almost certainly a better choice (e.g. at least all cases
where QList<T> would not use indirect storage, and possibly with some
heuristic for "small" and movable types).
> 2. Move QStringList and QByteArrayList over to inherit from QVector (that should be source compatible)
+1.
> 7. Make the implementation of QArrayList fully inline and deprecate the class.
-lots, as long as Qt has container classes. (I still want an STL version
of QArrayList, also...)
However, QList should be deprecated.
On 22/05/2019 12.41, Konstantin Tokarev wrote:
> In the latter QList can be replaced with
> std::vector<std::unique_ptr<T>> or QVector<std::unique_ptr<T>>
No, it can't. `QList<T>` has value semantics w.r.t. `T`. Your
"alternatives" have pointer semantics.
--
Matthew
More information about the Development
mailing list