[Development] QList

[Konstantin Tokarev]

26.04.2017, 08:04, "Marc Mutz" <marc.mutz at kdab.com>:
> On 2017-04-25 23:04, Thiago Macieira wrote:
>>  On Tuesday, 25 April 2017 17:49:16 -03 Alejandro Exojo wrote:
>>>  On Tuesday 25 April 2017 16:35:01 Thiago Macieira wrote:
>>>  > QVector and QList don't have the same API. They're slightly different.
>>>  > What'sm ore, QList has a beginning-of-list optimisation, whereas QVector
>>>  > doesn't (not even my copy, I stopped development shortly before I got to
>>>  > that part, even if I did add a QArrayData::GrowsBackward flag to support
>>>  > the case).
>>>  >
>>>  > (...)
>>>  >
>>>  > So, no, we can't implement that in Qt 5. In Qt 6, we've already agreed we
>>>  > don't want this mess, so QList as it is simply goes away.
>>>
>>>  By the way, which is the exit strategy for QQueue?
>>
>>  Do we need one?
>>
>>  The only reason that QQueue uses QList is because QList has that
>>  takeFirst()
>>  optimisation, while QVector does not. Once we implement that for
>>  QVector, we
>>  should be able to use QQueue with QVector too.
>
> FWIW: I'm against adding even more pessimising goodies to QVector. An
> area for push_front is such a goodie. The addition this causes is
> probably the reason why a QList, even for optimal payloads, is
> outperformed by QVector in my well-known benchmark from -Wmarc. Users
> that need a queue can use std::deque. If you don't iterate over it, it's
> a more than acceptable container.

std::deque is not a contiguous container, unlike QList or QVector, so it cannot be a
drop-in replacement.

>
> Thanks,
> Marc
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin