marc.mutz at kdab.com
Mon Mar 20 23:02:22 CET 2017
On Saturday 18 March 2017 10:51:06 Marc Mutz wrote:
> 4. Provide QArrayList for code that needs stability of references
> (stability statically checked in Qt 5, enforced in Qt 6).
There's disagreement over this last part. I have opted to provide a
constrained type alias QArrayList that can only be used to alias QLists that
already use QListData::IndirectLayout (= pointers to heap-allocated objects).
The intent was to allow QArrayList use in existing API. E.g., and I'm not sure
I'm proposing this, QList<QVariant> could be renamed to QArrayList<QVariant>
because it currently is. And some users may have come to depend on the
stability-of-references feature provided by inefficient QLists.
A type alias makes this trivial, because it introduces neither SC nor BC. It's
simply a way to document, and statically check, that that particular QList has
The other option would be to copy QList, strip out the optimisation that makes
it use layouts other than IndirectLayout and call the result QArrayList.
- migration of QLists used in APIs has to wait until Qt 6
- two almost identical code bases that are very likely to get out of sync,
accidentally or intentionally, before one of them gets ditched in Qt 6
- duplicate documentation to write, maintain, explain difference, ...
With the type alias, we just need to document the alias.
So, updated and refined tail of QList exit strategy would be:
4. Provide a type alias, QArrayList, for QList, constrained on actually
QListData::IndirectLayout QLists. Use it to mark QList uses that either
a. are (includes QVariant, QModelIndex, QImage, QPixmap, ...)
b. should conceptually be (excludes QVariant, QModelIndex, ...)
array lists (ie. arrays of pointers to heap-allocated objects) in a BC and
In Qt 6: (the -5- and -6- just refer to the Qt 5 and Qt 6 versions of the
5. Q5List -> Q6ArrayList, strip out non-IndirectLayout code, making it always
6. Provide a deprecated type alias Q6List that resolves to either Q6Vector or
Q6ArrayList, depending on similar conditions Q5List used before.
7. Replace all Q6List uses in API with either Q6ArrayList or Q6Vector.
- only one QList implementation to maintain and document in both Qt 5 and 6.
- adjustable SC:
Because this introduces a SiC/SC knob that's interesting to turn:
If Q6List uses the exact same conditions as Q5List, Q6List<UserType> would
have the same layout as Q5List<UserType>, making 'QList<UserType>' SC. But
Q6List<QVariant> would map to Q6ArrayList<QVariant> while the Qt API very
probably will have migrated to Q6Vector<QVariant>, making 'QList<QVariant>'
If we, say, dropped the isLarge trait from the condition, then some
Q6List<UserType> would switch memory layout, breaking stability of references
for some UserTypes, compared to Q5List, making 'QList<UserType>' SiC. But
Q6List<QVariant> would map to Q6Vector<QVariant>, making 'QList<QVariant>',
QList<QString> etc. SC.
Not sure where that knob will end up, but it's nice that it's there.
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
KDAB - The Qt, C++ and OpenGL Experts
More information about the Development