https://doc.qt.io/qt-5/qlist.html#details
QVector should be your default first choice. QVector<T> will usually give better performance than QList<T>, because QVector<T> always stores its items sequentially in memory, where QList<T> will allocate its items on the heap unless sizeof(T) <= sizeof(void*) and T has been declared to be either a Q_MOVABLE_TYPE or a Q_PRIMITIVE_TYPE using Q_DECLARE_TYPEINFO. See the Pros and Cons of Using QList for an explanation. Иван Комиссаров > 20 мая 2019 г., в 13:40, NIkolai Marchenko <enmarantis...@gmail.com> > написал(а): > > And on the matter of "you should have read all the discussions so you had > years to port away from QList" > > I am sorry, what? QList was never indicated as deprecated or somehow > undesirable in Qt docs far as I know and not every developer actively reads > these topics. > Moreover with all the discussions that were going on about "somehow saving > the user the pain for Qt6" I am sure a lot of ppl who *knew* still didn't > bother. > > This *really* is not something I expected being thrown around as a serious > argument here. > >> On Mon, May 20, 2019 at 2:18 PM NIkolai Marchenko <enmarantis...@gmail.com> >> wrote: >> I was speaking strictly of the cases where users already have auto used in >> their code _expecting it to signify owning container_. >> Imagine if they expect ownership in these cases. If the actual owning >> container that exists somewhere else somehow goes out of scope >> when the user expected to own it for a while (but declared it as auto) you >> are introducing nasty bugs while maintaining SC. >> >>> On Mon, May 20, 2019 at 12:35 PM Edward Welbourne <edward.welbou...@qt.io> >>> wrote: >>> On Thu, May 16, 2019 at 9:35 PM Vitaly Fanaskov <vitaly.fanas...@qt.io> >>> wrote: >>> >> If a user needs a regular container, range might be simply assigned to >>> >> it. >>> >>> NIkolai Marchenko (16 May 2019 20:38) replied >>> > It depends on what you expect the average usecase to be. >>> > If we assume that a regular container is generally more used then you are >>> > preventing ppl from "almost always auto" >>> >>> First: I don't believe we've committed to "almost always auto" as a Qt >>> coding style (it leaves the reader to work out what everything is, which >>> I - as a reviewer - really don't like). Being explicit about what type >>> of container you want to use has its virtues (albeit, as Marc points >>> out, auto's ambiguity is good when the API is in flux). >>> >>> Second: if we return a container, the API designer has to decide which >>> type of container to return, which forces the caller to do a conversion >>> if that wasn't the type they wanted. Returning a range lets the caller >>> chose how to store the values. >>> >>> However, that's only a win if the supplier wasn't already holding the >>> values in a container, which CoW lets us return cheaply. >>> >>> The win (assuming C++ ranges work enough like python generators) comes >>> when you're traversing some population of things and selecting some to >>> return, while skipping the rest; classically that might be implemented >>> as a traversal with a call-back object to act on each item; but a range >>> lets the caller just iterate over the results found, turning the >>> call-back's code into a loop's body, which is far easier to follow; or >>> collecting the results into a container of the caller's choosing. >>> >>> Eddy. > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
