STL or Qt container ?
To use :
std::(w)string and the STL containers exclusively and converting to the Qt equivalents, but already switched to QString and to find that using Qt’s containers.
When it comes to strings, QString offers much more complete functionality compared to std::basic_string and it is completely Unicode aware. It also an efficient COW implementation , which they come to rely on heavily.
- To offer the same COW implementation as in QString, which is extremely useful when it comes to using Qt’s foreach macro (which does a copy) and when using meta-types or signals and slots.
- STL-style iterators or Java-style iterators
- streamable with QDataStream
- To use extensively in Qt’s API
- Have a stable implementation across operating systems. A STL implementation must obey the C++ standard, but is free to do as it pleases (see the std::string COW controversy). Some STL implementations are especially bad.
- Provide hashes, which are not available unless you use TR1
” STL’s containers are optimized for raw speed, Qt’s container classes have been carefully designed to provide convenience, minimal memory usage, and minimal code expansion.”
The simple solution is:
Though in Qt land, code as the Qt’ians do. This is not just for readability/consistency concerns. Consider the store everything in a stl container then have to pass all that data over to a Qt function. To managing a bunch of code that copies things into/out-of Qt containers. The code is already dependent on Qt, so it does not like your making it any more “standard” by using stl containers. And the point of a container if everytime need to use it for anything useful, to copy it out into the corresponding Qt container.
The Qt containers are more limited than the STL ones:
- STL is standardized, not change with every Qt version (Qt 2 had QList (pointer-based) and QValueList (value-based); Qt 3 had QPtrList and QValueList; Qt 4 has QList, and it is nothing like QPtrList or QValueList).
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 5. In both Qt2->3 and Qt3->4 transitions, the changes in the Qt containers were among those requiring the most code churn.
- 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/).
- There is no Qt equivalent to std::deque.
- std::list has splice(). by using std::list, it need to splice().
- std::stack, std::queue properly aggregate their underlying container, and do not inherit , as QStack, QQueue do.
- QSet is like std::unordered_set, not like std::set.
- QList is a just weird.