[Development] Qt 5 types under consideration for deprecation / removal in Qt 6
apoenitz at t-online.de
Wed Jun 5 22:36:01 CEST 2019
On Tue, Jun 04, 2019 at 09:58:18PM -0700, Thiago Macieira wrote:
> On Tuesday, 4 June 2019 12:57:36 PDT Mutz, Marc via Development wrote:
> > You talk about a particular incarnation of stdlibs, I was talking about
> > the general case. Yes, in the case you describe, and _if_ libc++ is
> > configured to be compatible (which in the past you have complained is not
> > done correctly), then it may work. But take STLport vs. Rougewave on
> > older SunCC. Or Dinkumware vs. GCC on QNX.
> Yes, I've complained that most distros can't seem to compile them to be
> compatible correctly. But that's not Qt's problem that one (or most) of
> them fail to do their job properly.
It's not "Qt's problem" per se, but it's becoming the problem of Qt _users_
once Qt is not shielding them anymore.
And once that happens, Qt's utility for those user decreases, and *that* in
turn *might* become Qt's problem.
I am not saying it *will*, but it's a thing that needs to be taken into
And so far all real world data points I have is that the ongoing deprecations
are a major pain, continously eating into *my* time, and none of the alledged
advantages *including run time performance* ever came to state where it was
noticable, let alone obvious, in my daytime work, which incidentally happens
to a large degree within Qt Project code.
> In a properly configured environment, there could be users who want to perform
> this mixing.
> But no, I don't think we should use that as an argument for avoiding Standard
> Library API in our classes.
Neither me, actually. But it should also not serve as an excuse to run a
"quixotic crusade to de-Qt Qt" 
> For example, we should use std::unique_ptr.
... "when it makes sense". Not just because of IFONP.
 See https://valdyas.org/fading/hacking/happy-porting/ for a definition.
More information about the Development