[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