[Development] Question about QCoreApplicationData::*_libpaths

[Smith Martin]

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

Marc, you are still conflating optimal runtime efficiency with algorithmic correctness. QList is easy to use correctly in algorithms. It is almost hard to make a mistake. That is all "easy to use" means. It doesn't mean "easy to use while achieving optimal runtime efficiency."

You can't judge all programmers using your encyclopaedic knowledge as the standard. There is a lot to be learned by doing things correctly the easy way. It even makes learning to do the same things with optimal runtime efficiency more meaningful.

martin


________________________________________
From: Development <development-bounces at qt-project.org> on behalf of Marc Mutz <marc.mutz at kdab.com>
Sent: Tuesday, January 19, 2016 11:52 AM
To: development at qt-project.org
Subject: Re: [Development] Question about QCoreApplicationData::*_libpaths

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
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development