On 2017-05-24 15:12, Konstantin Tokarev wrote:
24.05.2017, 15:49, "NIkolai Marchenko" <[email protected]>:
A semi-sane idea that I think no one has suggested yet:
What if, starting from Qt6, QList becomes a wrapper for QArrayList
with a contructor from this type?
After all making existing code slightly _slower_ because of the
wrapping overhead is way less problematic than breaking it outright.
It will nudge the users of QLists that need to be fast to switch but
will leave users of "default no brainer container" happy as they
likely wouldn't even notice.
If existing Qt APIs switch from QList to QVector in Qt 6, such change
will make it hard to support both Qt 5 and Qt 6 in the same code base.
Which is why I suggested to make QList a type alias for QVector or
QArrayList, depending on some yet-to-be-determined criteria. Obvious
candidates algorithms are:
1. the one that QList currently uses.
This means that no QList user will see his own code break
(except when he depends on the padding present in today's
QList<T> when T is smaller than void*), but will either
need to port when interfacing with Qt API that moved to
QVector or incur the deep copy when QVector and QList are
implicitly converted to each other (an operation that
should be added and immediately deprecated).
2. historic QList use.
When a type T was customarily held in QList in Qt 5, QList<T>
maps to the container that is now used in Qt 6, regardless of
what (1) would have yielded. If T was not customarily held in
QVector, which includes the case that T is not a Qt library
type, it uses the algorithm from (1) to minimize breakages.
Under (1) QList<QVariant> would map to QArrayList<QVariant>, because
Q5List<QVariant> uses indirect memory layout (QVariant is too large),
while Qt 6 APIs will almost certainly use QVector for holding QVariants.
Under (2) we'd therefore map QList<QVariant> to QVector<QVariant>,
because that's what allows clients to continue to use QList<QVariant>
for the same API in both Qt 5 and 6.
I'm tending towards (2) these days.
Thanks,
Marc
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
