[Development] Question about QCoreApplicationData::*_libpaths
marc.mutz at kdab.com
Tue Jan 19 13:50:53 CET 2016
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.
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
KDAB - The Qt Experts
More information about the Development