On Wednesday, 5 June 2019 13:36:01 PDT André Pönitz wrote:
> > 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.
Technically true, but I don't think it's actually a very relevant fact, for
two reasons:
1) no one really wants to mix C++ standard libraries, despite the option
being there
2) the boat has sailed: people use other libraries like Boost that do use C++
Standard Library API, which means those codebases are already affected
> > 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]
I agree with you. You know I dislike the Standard Library API and I really
wish not to read ".empty()" in Qt code and wonder if that is in the
imperative. After all, if it's ok for "clear", why not "empty"?
But I am not in the mood for reimplementing perfectly good API. I may find
that std::chrono is overengineered, but it is something I can work with.
And I am not above wrapping bad Standard Library API when I think we can do
better. Quod vide QRandomGenerator.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
