[Development] Use of std::function in Qt API
Marc Mutz
marc.mutz at kdab.com
Fri Mar 17 21:02:36 CET 2017
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.mutz at 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
More information about the Development
mailing list