Do you know is there is any official policy published? I’ve tried to look into both internet and intranet, but found pretty much nothing.
I entirely agree with increase of using new language features and STL, but it should be done wisely and under well-defined policy. If we don’t have one, we need to develop it. Without an official document users cannot rely on Qt. We also might easily violate ABI-compatibility policy and so on. -- Best Regards, Fanaskov Vitaly Senior Software Engineer The Qt Company / Qt Quick and Widgets Team On 29 May 2019, at 17:17, Mutz, Marc via Development <development@qt-project.org<mailto:development@qt-project.org>> wrote: 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<mailto:Development@qt-project.org> https://lists.qt-project.org/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
