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 <[email protected]> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
