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

Kevin Kofler kevin.kofler at chello.at
Tue Jul 21 02:57:34 CEST 2015


Marc Mutz wrote:
> 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.

So your dislike of QList is so strong that you want to eliminate it even 
where it IS the most efficient solution? That doesn't make sense, 
considering that you are bringing up performance as the primary argument 
against it.

> 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.

Well, if I'm writing Qt-based code, I don't want to use STL containers. They 
make the code inconsistent, and they are also less convenient to use because 
of the lack of implicit sharing. (Sure, that makes them more efficient if 
you are NOT copying the containers around, but it makes it harder to do the 
right thing.)

        Kevin Kofler




More information about the Development mailing list