[Development] Use of std::function in Qt API
thiago.macieira at intel.com
Fri Mar 17 21:12:57 CET 2017
Em sexta-feira, 17 de março de 2017, às 13:02:36 PDT, Marc Mutz escreveu:
> 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".
Actually, I meant what I said but I realise that it's not accurate. I was
going to say "our dependencies", but I wanted to constrain what we actually do
expose. We depend on libdoubleconversion and libpcre2, but those aren't
exposed in the API. But what I constrained to is inaccurate.
> We use Mac types in the ABI. We
> probably use Windows types in the ABI. We provide platform-native handles,
> for one.
Right. And specialised libraries like QX11Extras also expose Xlib types.
> 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.
Right, and QDBusConnection also provides a void* to get the DBusConnection,
but I've warned that it may change. Note that exposing a void* actually means
we *don't* depend on their ABI and, if they break it, our ABI isn't affected.
The code inside network/ssl or dbus can deal with the apparent breakage and
hide the problem, if necessary.
> 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.
I'd insist we keep it a void* (I invite you to take a look at
qsslcertificate_winrt.cpp) the same way that the native event filter also does
type-erasure. Converting back to the original type is SEP.
> Let's say it like this:
> ... provided the libraries, toolchain and build settings (incl. compiler
> switches) provide binary compatibility, too.
Agreed, but I want a whitelist of libraries whose ABI we expose in our ABI.
Libraries that are mere backends of what we implement should not be exposed.
> iow: Qt will not introduce spurious binary incompatibilites not already
> present in libraries, toolchains and settings Qt depends on.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development