[Development] Qt 5 types under consideration for deprecation / removal in Qt 6
marc at kdab.com
Wed May 29 17:17:15 CEST 2019
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
> 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
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.
More information about the Development