Marc Mutz wrote:
> No-one, not even experts understand QList, really. So it may appear to be
> easy to use, but is actually a container only absolute experst should use.
QList gives people who just don't care about the internals something closer
to optimal than any of the containers optimized for a specific use case. The
worst case for QList operations is O(n+m) (for a list of n elements of size
≤ m each), rather than O(n m) as for QVector or std::vector (with the
obvious exception of sorting, which, assuming that 2 elements can be
compared in O(1), is O(m n log(n)) for QVector and std::vector and only
O(n log n) for QList). So I think it is a GOOD class for beginners to use.
Of course one can use a std::vector<T *>, but then you lose the value
semantics.
> And a QVector provides exactly the same guarantees as a std::vector. How
> come one is easier to use than the other? Because QVector has indexOf()?
> And what about those cases where the user wants to find an element by just
> a field? They will write for loops, most likely, and not use algorithms.
Sure, algorithms are more flexible in theory, but they are also less
intuitive than a straightforward API such as indexOf. That's the very reason
people are tempted to write loops rather than using algorithms. There's
nothing preventing people from using algorithms on QVector, is there? The
indexOf method surely isn't it.
> The crucial point here is that there's no "better" Qt API for this than
> what exists on std::vector. Instead, there's a much more complicated API
> by sheer volume and duplication, without being near extensive enough for
> even very simple tasks. At some point, the question must be asked whether
> CoW and append() vs. push_back() do not become more of a burden than a
> merit. And whether we need three names for size().
What you call "volume", I call "completeness". And most of the "duplication"
is compatibility with the ugly STL names (source compatibility, template
algorithm compatibility). So it's the STL's fault that we have duplication.
Just don't use the ugly STL names, ever. (push_back does not even comply to
Qt naming guidelines. Always use append/prepend/removeLast/removeFirst
instead of push_back/push_front/pop_back/pop_front. And Qt also has a real
pop unlike the misleadingly-named STL one: takeLast/takeFirst.)
And the reason the STL API is horrible is not only the incompleteness, but
also the terse, inconsistent (e.g., std::queue::front vs.
std::priority_queue::top) and misleading (e.g., pop* methods that do not
return the popped element) names.
>> The main question IMO is how we can bring these two worlds closer
>> together for Qt 6 (or maybe even to some extent in Qt 5.x).
>
> My answer would be to use std containers exclusively, and write a
> wagonload full of Qt-level docs about them, ie. integrate them into the Qt
> docs.
And my answer would be to ban the std containers from Qt entirely and
restore support for QT_NO_STL.
Kevin Kofler
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
