On 2019-05-29 16:06, Vitaly Fanaskov wrote:
=== QAtomic -> std::atomic ===
It already is just a thin wrapper around std::atomic, so there's not
much point keeping it.
There is the interesting question in light of this: are we really going
to widely use std::* in public interfaces of Qt? If so, how all related
mess is supposed to be handled? I know that we already use some of
them,
for example, in QTimer and QString, but these cases are minor.
This decision should be very well justified and clearly defined
somewhere before making suggestions like above.
AFAIK, this was decided long ago (at least two years). The problem used
to be that Qt, by coincidence, didn't care which std library the user
application linked to, because all its STL use was either internal or in
inline functions. This used to have some merit on OSX, and could have
had some merit on Linux had distributions compiled libc++ against GCC's
language library to make it compatible with libstdc++, which, however
most didn't.
But of course, that's a fallacy, because as soon as Qt internally uses
said inline functions, every use of them by the user with a different
STL is an ODR violation and therefore UB. So, again AFAICT, the decision
was that we can use std types in the API now, even when not inline.
Someone correct me if I'm wrong.
What changed since then is that we can now assume many more of the C++11
types to be available unconditionally.
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
