[Development] Proposal: Deprecate QVector in Qt 6
mwoehlke.floss at gmail.com
Fri May 22 19:26:05 CEST 2020
On 20/05/2020 13.15, Lars Knoll wrote:
> On 20 May 2020, at 17:34, Matthew Woehlke wrote:
>> On 20/05/2020 09.11, Lars Knoll wrote:
>>> Here’s what we will do:
>>> * QList and QVector are aliases for each other
>>> * We make QList the main type, and QVector an alias to it
>>> * We keep both names, QList and QVector. None of them is deprecated
>> While I don't object to this as such, can someone remind me what is
>> the solution for people that *need* the semantics of old QList
>> (either reference stability or indirect allocation)?
> There’s an option to provide a Q5List in qt5compat.
That's IMO a lousy option.
> Of course one could also add a new class to Qt 6 that always
> allocates indirectly.
This would be much better. I thought there had been talk of doing such?
> But in that case I would propose to redesign it, so that is uses
> block allocations to avoid at least some of the overhead of QList in
> Qt 5.
That sounds like std::colony, which has different trade-offs; in
particular, it cannot be indexed (no random access). I don't necessarily
object to such a container type (although if we do get std::colony,
there is less of an argument for it), but if I have to choose one, I
would prefer to keep Qt5 QList as it was, especially as that is much
more feasible due to the additional work of adding a new type.
>> Also, will the new QVector/QList have the prepend optimization of
>> old QList?
> Yes, see https://bugreports.qt.io/browse/QTBUG-84320
Cool, thanks for the info.
More information about the Development