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 consideration. 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" [1] > For example, we should use std::unique_ptr. ... "when it makes sense". Not just because of IFONP. Andre' [1] See https://valdyas.org/fading/hacking/happy-porting/ for a definition. _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
