[Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
Kevin Kofler
kevin.kofler at chello.at
Tue Jul 21 02:48:12 CEST 2015
Milian Wolff wrote:
> Did you actually profile this? I don't see how a QVector could lead to
> "allocation hell", where QList would not be much worse.
If you have large objects, and insert or remove items within the list,
QVector will have to move (or even copy&delete, if they're not movable)
large amounts of data. Unless you use a QVector<T*>, but that loses the
value semantics in several places. And a QLinkedList is not an option if you
also need O(1) (or anything faster than O(n), even) item retrieval. Pointer
arrays have their advantages.
IMHO, QList is the safest container to recommend to an inexperienced
programmer, because there are very few operations that have a suboptimal
complexity class. (Of course, abuse of contains or indexOf/lastIndexOf where
a QHash or QMap should be used is problematic, but that's true for any list
type.) Sure, the constant factor is often not optimal (though in common
cases such as the implicitly-shared Qt classes, the code is actually
supposed to do the exact same thing as QVector, so there shouldn't be any
difference in those cases), but it is much better than hitting the worst
case of QVector or QLinkedList because you just picked what the
documentation told you without realizing the performance impact.
If we want the most efficient code at all costs, we need to write in
assembly, not C++.
Kevin Kofler
More information about the Development
mailing list