[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