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 IndirectLayout. 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. Disadvantages: - 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 SC way. In Qt 6: (the -5- and -6- just refer to the Qt 5 and Qt 6 versions of the names): 5. Q5List -> Q6ArrayList, strip out non-IndirectLayout code, making it always use IndirectLayout. 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. Advantages: - 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>' SiC. 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. Thanks, Marc -- Marc Mutz <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
