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.
--
Matthew
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
