[Development] QList for Qt 6

[Иван Комиссаров]

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 <enmarantispam at 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 <enmarantispam at 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.welbourne at qt.io> wrote:
>>> On Thu, May 16, 2019 at 9:35 PM Vitaly Fanaskov <vitaly.fanaskov at 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 at qt-project.org
> https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190520/8ed7a5f9/attachment.html>