Hi, I'll never manage to eradicate inefficient QLists if people continue to add new ones :) So here are some things I'd like _everyone_ to watch out for in reviews and mercilessly -1:
- using QList - not using Q_DECLARE_TYPEINFO Let me qualify that a bit: QList<C> is a _very_ bad idea for virtually any C, because the minutest of mistakes (and the default behaviour _is_ a mistake) can render it utterly and unacceptably inefficient. I won't give you the whole story (google "QList harmful" for that), but never, ever use QList<C> *unless*: - sizeof(C) == sizeof(void*) (*both* on 64 and 32-bit platforms!) _and_ C has been declared Q_MOVABLE_TYPE or Q_PRIMITIVE_TYPE -or- - the use is unescapable, because other parts of Qt use it (e.g. QVariant, QModelIndex). The latter doesn't mean that you should _always_ use QList for QVariant or QModelIndex. If all you're doing is local to your class, then by all means use a QVector. QVector is the correct default container. If you actually need list behaviour (ie. linked lists), use QLinkedList instead. It tends to be _faster_ than QList. In private implementation, also consider using std::vector<C>, esp. if you never copy it and C is (explictly or implicitly) move-enabled. It typically produces up to 1KiB less executable code than QVector. *Per instantiation*. If in *any* kind of doubt whether QList is acceptable, or any of your container choices, feel free to add me as a reviewer. And please, whenever you add a new type (not just class, *any* type, incl. enums, but excluding QFlags (which are automatically primitive)), strongly consider Q_DECLARE_METATYPE with the appropriate flag (yes, even Q_COMPLEX_TYPE). About the only time this can be considered optional is for polymorphic classes. It should become second nature to Q_DECLARE_TYPEINFO. It should be considered a _must_ to Q_DECLARE_TYPEINFO any type that is put into a QVector, QList or QVariant. In fact, my local copy enforces this at compile-time. I hope to push this work at some point, but of course, that means that each and every occurrence in Qt itself first needs to be fixed, and even then, we can only enable it as an opt-in to not break user code (even if it deserves to be broken). Thanks, Marc -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development