I thought QVector and the older QList could decide that the container's allocated space was too big compared to the the number of elements and reallocate on erase() too. This doesn't seem like a new requirement. Actually, this is something not done in Qt 5.15 as far as I can see: QList does not seem to have such a code path at all (and no mentions of such), QVector has a fixme yet follows std::vector policy looks like. But yes, good job bringing this up. In Qt 6 code base we also do the shrinking in erase. So this already is not aligned with std::vector.
-- Best Regards, Andrei ________________________________ From: Development <[email protected]> on behalf of Thiago Macieira <[email protected]> Sent: Wednesday, September 2, 2020 5:37 PM To: [email protected] <[email protected]> Subject: Re: [Development] Important recent changes in QList/QString/QByteArray On Wednesday, 2 September 2020 05:28:33 PDT Ville Voutilainen wrote: > No. I mean "before", not "after". That's how std::vector works. An > erase is a shrinking operation > that keeps everything before the erased position untouched and > left-shifts everything after it. If you > want a prepend optimization, you can get it without changing the way > erase works and what the > invalidation guarantees of erase are, so I'd like to understand what > in our implementation strategy > necessitates this change to those guarantees. I thought QVector and the older QList could decide that the container's allocated space was too big compared to the the number of elements and reallocate on erase() too. This doesn't seem like a new requirement. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
