[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