[Development] QList

[Marc Mutz]

On 2017-05-24 15:12, Konstantin Tokarev wrote:
> 24.05.2017, 15:49, "NIkolai Marchenko" <enmarantispam at gmail.com>:
>> 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