Il 20/01/2016 22:25, Kevin Kofler ha scritto:
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.
This kind of measurement is way too approximative for the real world. You should measure quantities that actually make a difference, for instance: how many cache misses do you get when doing these various operations? How many allocations/deallocations? How big is each allocation?
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.
This poses further questions down the line, such as whether it's "ok" having an index API based on signed integers. (It is for convenience, it is not for correctness, but I guess that's all the topic here, 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.
Renaming a function is not a big deal (heck, we could even provide a std::vector subclass with convenience functions! Would that make everyone happy?). Having "a real pop" is the consequence of Qt not being exception safe. Since you can't build an exception-safe pop that returns the popped value, the STL (which cares about exception safety and wants containers with the strong guarantee) does not provide pop-and-return functions. So, seeing the glass half empty: Qt containers are unsound for general-purpose storage.
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.
Which is never going to happen since the STL containers are superior in performance and code size and we want to use them extensively inside Qt. If/how/when expose STL types in our APIs is all to be seen...
... can we go back thinking about that? Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
