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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
