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

[Marc Mutz]

On Tuesday 21 July 2015 02:57:34 Kevin Kofler wrote:
> 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.

It makes perfect sense: A container should not subtle change memory layout and 
switch guarantees in such a way that only experts know what it actually does. 
That an array-list *might* be the most efficient container for certain types 
and certain operations, no-one disputes.

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

Your code, your choice.

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