[Development] std:: in Qt ABI (was: Qt LTS & C++11 plans)

[Thiago Macieira]

On Wednesday 01 July 2015 07:20:18 Koehne Kai wrote:
> What I think would be very helpful is std::function though. We've a couple
> of places where we take function pointers with its awkward design and
> limitations. In others we start to have classes with just one virtual
> member ... This is all much more elegantly solved by just taking a
> std::function.

That is true, no doubt about it.

> > Since we're talking about *ABI*, it stands to reason we're talking about
> > mandatory features, so outside of any #ifdefs that may change between Qt's
> > build and the user application's. That means any such feature depending on
> > a C++11 library feature should be protected by a configure-time check and
> > C++a  #define in qconfig.h
> 
> I guess this is only a limit until we require C++11 (planned for Qt 5.7)?

We're not requiring all of C++11 and we only discussed core language features. 
We did not discuss standard library features at all, especially since we have 
no data on what got supported and when, including when vendors replace the 
library with a third-party implementations (Dinkumware in QNX, for example).

Even looking at just libstdc++, we cannot be sure that the library headers 
match the GCC version being used, as it could be older. There's no 
monotonically-increasing macro that indicates its version number...

I'd rather SG-10 had standardised all the features we need in SD-6, but the 
__cpp_lib_xxx macros are quite limited. There's none for std::function, for 
example.

Even worse, we're talking about ABI here, so there needs to be no change due 
to a compiler or standard library update. So, no, standard library feature 
usages require a configure check and a macro in qconfig.h.

Good luck writing such tests.

> > Given our horrible configure script and configure.exe
> > source code, writing such checks are difficult and time-consuming. More
> > likely than not, we'll get it wrong.
> > 
> > And finally, I am against it because libc++ and libstdc++ co-existence is
> > still a goal, even on OS X.
> 
> My understanding is that most (all?) Linux distributions focus on  libc++.
> On OS X it's libstdc++.

The opposite, like your other email says.

That is true. And like I posted before, there doesn't seem to be any Linux 
distribution that builds libc++ correctly so that it can actually share ABI 
with libstdc++.

That leaves OS X and the BSDs. My point is that it's still a goal, even on 
OS X. The same way that some people still use 32-bit builds on OS X because 
they need to link to a proprietary module only provided in 32-bit, it's 
possible that such proprietary modules are linked to and require use of 
libstdc++. Therefore, if we used libc++ in our own ABI, such users would have 
to put up a firewall between the two modules.

It's hard to quantify how difficult that would be, though. It's a lot easier 
than the 32-bit vs 64-bit case, so maybe we shouldn't consider it a problem.

But my opinion stands that we should leave as-is and not require the ABI.

> An ABI incompatibility in Qt would affect only apps that
> - don't compile Qt themselves, but use the prebuilt ones (from distribution,
> or from binary installers) - link against 'the other' C++ runtime library
> themselves, or link against libraries that do so

The 5.5.0 changelog states that builds on OS X with libstdc++ are deprecated 
and will be removed for 5.7. That did not apply to the application code 
itself, which is the discussion here.

If we remove the ability of the application code to use a different C library 
than Qt itself, then we effectively remove everyone's ability of using 
libstdc++ on OS X, short of putting up the firewall like I described.

> I'm wondering how big the use case really is. In the worst case we can also
> provide different builds ourselves (Not that I want to pitch this, but we
> do the stunt on Windows already).

I don't know how big it is either. It probably happens as often as the need 
for 32-bit on OS X, though the solutions could be different.

Does anyone know how often 32-bit on OS X is required?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center