On Friday 17 March 2017 17:16:39 Thiago Macieira wrote: > Em sexta-feira, 17 de março de 2017, às 03:31:23 PDT, Marc Mutz escreveu: > > provided the same external libraries, and the same toolchain are used to > > build the two Qt releases. > The problem is this line here. People expect to upgrade other libraries. > We should say that we guarantee our ABI provided that libc and the C++ > library guarantee it too. We won't expose any other library's types in our > ABI.
This is false already today. Or only true for a definition of "libc" that approximates "all libraries Qt depends on". We use Mac types in the ABI. We probably use Windows types in the ABI. We provide platform-native handles, for one. We expose OpenSSL in our ABI. Yes, we hide it behind a void* Qt::HANDLE, but any user of QSslCertificate::handle() already depends on OpenSSL. This is a SEP. Don't insist on making all libraries' ABI stability _our_ problem. If it wasn't for this rule, QSslCertificate::handle() could return the real thing, depending on the platform, saving the user the need to write dangerous casts. Let's say it like this: ... provided the libraries, toolchain and build settings (incl. compiler switches) provide binary compatibility, too. iow: Qt will not introduce spurious binary incompatibilites not already present in libraries, toolchains and settings Qt depends on. Thanks, Marc -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development