[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