[Development] Question about QCoreApplicationData::*_libpaths

[Knoll Lars]

On 19/01/16 13:50, "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 11:47:29 Knoll Lars wrote:
>> >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. 
>
>So ... that means we're stuck with them until eternity?

Things are not just black and white. But we can’t do a Qt6 that simply removes all of them completely. We’d leave most of our users behind on Qt 5 forever. So we have to find better, and maybe more incremental, ways to handle this. With a radical 'let’s throw them all away' approach we will leave all our current users behind.
>
>If so, let me suggest that you put some dev force behind the containers again. 
>They have seriously fallen behind the std ones (I remember a time when QVector 
>outperformed std::vector, ok on SunCC without stlport, but still). Apparently, 
>no-one from the community bothers enough about this (me included, even though 
>I hack them a bit here and there).
>
>Status quo in libraries equals bit-rot. The containers are _not_ "good 
>enough". E.g. QVector seriously needs to support move-only types (like 
>unique_ptr) in a C++11 world. Oops... it never will... it's CoWed...
>
>I have nothing against a *superior* Qt replacement for std classes, with 
>proper interop. Like QString. I don't like *inferior* solutions that not much 
>more than internal classes which are forced onto users because they are touted 
>as superior in the docs and unavoidable by way of being ubiquitously used in 
>other Qt API.

Now that’s being polemic. They have been designed as public classes. You might not like them, and some parts we would certainly do differently today. But when they got written for Qt 4.0, we did put thoughts behind them and aimed to make them as good and versatile as possible.
>
>For every user that uses Qt because of the containers, you will probably find  
>ten that don't/wouldn't use it for the same reason.

I doubt that. I am convinced that for most people that have a real product to create, the most important thing is to get the product out. For many use cases, Qt makes that easier than any other solution on C++. 

Cheers,
Lars