[Development] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

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