[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