26.04.2017, 08:04, "Marc Mutz" <[email protected]>: > 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
