[Development] Qt 5 types under consideration for deprecation / removal in Qt 6

Vitaly Fanaskov vitaly.fanaskov at qt.io
Wed May 29 19:29:37 CEST 2019


Well, but what about MSVC, for example, or some other compilers/|platforms? This is rhetorical question, of course. I just want to say, that we cannot guarantee this sort of compatibility for all build configurations. Hence, this is unreliable unless we have a sort of public contract like “we guarantee this, this, and that under some circumstances”.

--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

On 29 May 2019, at 17:30, Olivier Goffart <olivier at woboq.com<mailto:olivier at woboq.com>> wrote:

On 29.05.19 17:17, Mutz, Marc via Development wrote:
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.

I believe you are right. But binary compatibility, as a whole, is a ODR violation, and therefore is UB. (Unless we really do not touch any of the existing class in a public header files, not even to add a typedef or a method in them)

In practice, however, it works. Same as changing the stdlib, because they also keeps binary compatibility across version and libc++ and libstdcpp are in different namespace.

--
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190529/a5e140c4/attachment-0001.html>


More information about the Development mailing list