[Development] Use of std::function in Qt API
Thiago Macieira
thiago.macieira at intel.com
Tue Mar 14 16:54:06 CET 2017
On terça-feira, 14 de março de 2017 02:33:44 PDT Simon Hausmann wrote:
> Hi,
>
>
> I understand that there are limitations (to put it mildly) regarding the use
> of API from the C++ standard library in Qt API itself due to the inability
> to extend our binary compatibility promise. I'm curious though whether
> std::function falls under the same umbrella?
It does. libstdc++ has shown they have no qualms about breaking binary
compatibility in downstream libraries, as they've done it twice in the past
three releases (the most notable case was std::string).
What we have to ask ourselves is whether we want to say that is not our
problem. For example, the std::string breakage caused any application or
library that used it in its API to need to be recompiled. Besides Qt, there
aren't many libraries that avoid it. So if the underlying C++ Standard Library
breaks ABI, should we try to work around it? Or should we punt the problem to
the user?
There's also the case of libc++ and libstdc++ mixing. That used to be a macOS
question, but it's nowadays mostly a Linux question. However, unlike macOS,
Linux distributors and developers using libc++ don't know how to do it
properly, so libc++ and libstdc++ can't be *actually* mixed, as they don't
share the low-level ABI. If that is going to remain as is, then mixing is not
possible anyway and ceases to be a use-case for us.
> I understand that we permit the use of std::function in Windows specific API
> of QProcess, which may or may not be different. However I'm curious about
> this in the context of API that is intended to be fully cross-platform.
Now that MSVC 2017 does retain binary compatibility with 2015, we have to
revisit that position if Microsoft starts using inline namespaces to break
ABI.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development
mailing list