[Development] Question about QCoreApplicationData::*_libpaths

[Knoll Lars]

On 19/01/16 11:52, "Development on behalf of Marc Mutz" <development-bounces at qt-project.org on behalf of marc.mutz at kdab.com> wrote:



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

Let’s stop arguing about QList, please. We all agree that this class has larger problems.

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

Come on. All of us use the Qt containers and he APIs do cover most of the common use cases.

Yes, there is some duplication, and one can argue whether we for example need constBegin(). On the other hand I still find it a lot more readable than the STL cbegin().

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

I have not seen many people having problems with those. 
>
>> 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.

Something I would probably support if we started a new toolkit from scratch today (even though I still don’t like some of the API naming decisions of the STL). But we have these classes, and there are probably hundreds of millions of lines of code out there using them. So removing them and breaking all that code is simply not an option. 

Cheers,
Lars