[Development] Question about QCoreApplicationData::*_libpaths

[Giuseppe D'Angelo]

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.dangelo at kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4068 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160120/5dc56892/attachment.bin>