[Development] QList for Qt 6

[NIkolai Marchenko]

That's not equal to directly discouraging the use of qlist. Especially
since they have different interfaces.
That's "blah blah blah, if you are interested in details blah blah blah"

I've read it, not everyone did, I am sure of it. And it's not equal to
directly stating: "if you continue using qlist you are going to have a bad
time (tm) come Qt6"


On Mon, May 20, 2019 at 3:02 PM Иван Комиссаров <abbapoh at gmail.com> wrote:

> https://doc.qt.io/qt-5/qlist.html#details
>
>
>    - QVector <https://doc.qt.io/qt-5/qvector.html> should be your default
>    first choice. QVector <https://doc.qt.io/qt-5/qvector.html><T> will
>    usually give better performance than QList
>    <https://doc.qt.io/qt-5/qlist.html><T>, because QVector
>    <https://doc.qt.io/qt-5/qvector.html><T> always stores its items
>    sequentially in memory, where QList <https://doc.qt.io/qt-5/qlist.html><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
>    <https://doc.qt.io/qt-5/qtglobal.html#Q_DECLARE_TYPEINFO>. See the Pros
>    and Cons of Using QList
>    <http://marcmutz.wordpress.com/effective-qt/containers/#containers-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/9bddb4c8/attachment.html>