(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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
