STL or Qt containers?

Question

What are the pros and cons of using Qt containers (QMap, QVector, etc.) over their STL equivalent?

I can see one reason to prefer Qt:

Answer 1

The Qt containers are more limited than the STL ones. A few examples of where the STL ones are superior (all of these I have hit in the past):

• STL is standardized, doesn't change with every Qt version (Qt 2 had QList (pointer-based) and QValueList (value-based); Qt 3 had QPtrList and QValueList; Qt 4 now has QList, and it's nothing at all like QPtrList or QValueList). Qt 6 will have a QList that's QVector while QVector will be deprecated. Even if you end up using the Qt containers, use the STL-compatible API subset (ie. push_back(), not append(); front(), not first(), ...) to avoid porting yet again come Qt 6. In both Qt2->3 and Qt3->4 transitions, the changes in the Qt containers were among those requiring the most code churn. I expect the same for Qt5->6.
• STL bidirectional containers all have rbegin()/rend(), making reverse iteration symmetric to forward iteration. Not all Qt containers have them (the associative ones don't), so reverse iteration is needlessly complicated.
• STL containers have range-insert() from different, but compatible, iterator types, making std::copy() much less often needed.
• STL containers have an Allocator template argument, making custom memory management trivial (typedef required), compared with Qt (fork of QLineEdit required for s/QString/secqstring/). EDIT 20171220: This cuts Qt off of advances in allocator design following C++11 and C++17, cf. e.g. John Lakos' talk (part 2).
• There's no Qt equivalent to std::deque.
• std::list has splice(). Whenever I find myself using std::list, it's because I need splice().
• std::stack, std::queue properly aggregate their underlying container, and don't inherit it, as QStack, QQueue do.
• QSet is like std::unordered_set, not like std::set.
• QList is a just weird.

Many of the above could be solved quite easily in Qt, but the container library in Qt seems to experience a lack of development focus at the moment.

EDIT 20150106: After having spent some time trying to bring C++11-support to Qt 5 container classes, I have decided that it's not worth the work. If you look at the work that is being put into C++ standard library implementations, it's quite clear that the Qt classes will never catch up. We've released Qt 5.4 now and QVector still doesn't move elements on reallocations, doesn't have emplace_back() or rvalue-push_back()... We also recently rejected a QOptional class template, waiting for std::optional instead. Likewise for std::unique_ptr. I hope that trend continues.

EDIT 20201009: Come Qt 6, they will again rewrite their containers in incompatible ways:

• QVector will be renamed QList, so you lose stabiliy-of-reference when using QList.
• QVector (the name) will be deprecated. QLinkedList will be removed.
• QHash and QSet are now Open-Addressing Hash Tables, also losing stability-of-reference guarantees
• QMap will be backed by std::map, possibly changing insertion behaviour and, for QMultiMap, order of equivalent elements.
• Qt container sizes and indexes will become qsizetype (more or less std::ptrdiff_t) (was: int).

So, if you want to rewrite your container-using code, then go ahead with the Qt containers. Everyone else enjoys decades of stability with the STL containers.