[Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Marc Mutz]

On Sunday 12 July 2015 13:11:54 Smith Martin wrote:
> >To me it looks like you're trying to argue about a very particular use of
> >QList. At that level of details, it has no business being in the docs.
> 
> And yet you wrote a blog about it instead of submitting the info to us to
> update the QList documentation. Currently, the QList page says this:
>
> "QList<T>, QLinkedList<T>, and QVector<T> provide similar functionality.
> Here's an overview: For most purposes, QList is the right class to use.
> Its index-based API is more convenient than QLinkedList's iterator-based
> API, and it is usually faster than QVector because of the way it stores
> its items in memory. It also expands to less code in your executable."
> 
> If your argument is correct, then all three of those sentences are false,
> yes?

Correct.

> What do you mean here when you say default: "If you want to update the
> docs, as a first approximation, write that QVector is the default
> seqential (and, if it wasn't so awkward to use, also the default
> associative) container (even though it's not currently reflected in the Qt
> API)."
> 
> Do you mean: The user should always choose QVector over QList unless he has
> a specific reason (not listed) to use QList?

Correct. But I gave reasons to use QList in the OP.

> >Better provide a benchmark into which users can easily plug their own
> >types and that plots relative performance of various containers at
> >various sizes. Then they can use that on their platform, on their type,
> >with their access patterns to determine which container to choose.
> 
> I doubt that benchmark tool would work as well as just writing your
> application with QList, benchmarking it, and then replacing QList with
> QVector and benchmarking it again. Apparently, it is quite easy to replace
> QList with QVector.

Wrong way around. You should start with QVector. For both performance reasons 
and - as I repeatedly said now - as a service to the reader of the code who 
then doesn't have to perform a deep analysis of the contained type first to 
understand whether that particular QList is a vector or a list.

I maintain that because of that Janus-headedness of QList, QList should be 
avoided at any cost for types for which it has not already been established as 
public API, even if the alternatives, QVector or QLinkedList, depending on the 
kind of container you wanted QList to be, should perform (a little) worse. 
BTW: if you need something between a vector and a list, there's always 
std::deque. 

And that benchmark is not about QList vs. QVector. If a developer needs a 
sequential container, he needs to choose between QList, QLinkedList, QVector, 
QVarLengthArray, QSet, std::vector, std::set, std::deque, std::list, 
std::forward_list, and C array. For associative containers, between QMap, 
QHash, std::map, std::unordered_map and any sequential container of QPair or 
std::pair.

That's just the ones that Qt and the STL contain, excluding container adaptors 
such as stack, queue, and cache. In Boost, you will find bimap and *much* more 
complicated containers that rival SQL tables for flexibility, and from Google 
you can download OA hash table implementations.

Picking a container that has proven to be a good fit for a lot of workloads 
and then benchmarking is the only way to make such a choice. std::vector is 
such a container. QList most definitly not.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts