[Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

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?

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.

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.

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