[Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

On Tuesday 19 January 2016 09:39:02 Knoll Lars wrote:
> On 15/01/16 23:20, "Development on behalf of Thiago Macieira" <development-
bounces at qt-project.org on behalf of thiago.macieira at intel.com> wrote:
> >On Friday 15 January 2016 18:42:43 Marc Mutz wrote:
> >> And you will see it over and over again until enough people are fixing
> >> premature pessimisations in existing Qt code. There's a notable increase
> >> already. But it takes a long time to turn a supertanker around...
> >
> >Some of us call them "trade-offs". Every trade-off is a pessimisation
> >somewhere for an optimisation somewhere else. Often, they're not measured
> >in the same units or not quantifiable at all.
> >
> >API quality and consistency fall under those definitions.
> 
> Exactly this.
> 
> >> And no, I cannot believe that using the Qt containers leads to faster
> >> applications. It may lead to applications faster, but not to faster
> >> applications.
> >
> >Exactly. TTM is a significant factor and we all know Paretto's Law (80-20
> >rule).
> 
> And this. Let’s not forget to ask ourselves the question why many
> developers use Qt in C++ development, often even in the case where they
> don’t need a UI. For the past 20 years a lot of our focus has been on
> making development easy, and creating APIs that serve that goal. This
> means that we are in many case optimising for TTM more than for ultimate
> speed.
> 
> I think we agree that std containers are in many cases faster than the Qt
> containers. But they are harder to use and especially developers that come
> from other languages often appreciate the ease of use of the Qt
> containers.

I always cringe when I hear this. What, specifically, do you mean by "easier to 
use"?

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.

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.

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().

> 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.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts