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

[Koehne Kai]

> -----Original Message-----
> From: development-bounces+kai.koehne=theqtcompany.com at qt-project.org
> [mailto:development-bounces+kai.koehne=theqtcompany.com at qt-project.org]
> On Behalf Of Thiago Macieira
> Sent: Tuesday, June 30, 2015 10:17 PM
> To: development at qt-project.org
> Subject: Re: [Development] Qt LTS & C++11 plans
>
> On Tuesday 30 June 2015 18:16:34 Olivier Goffart wrote:
> > On Friday 26. June 2015 08:41:11 Thiago Macieira wrote:
> > > On Friday 26 June 2015 11:59:11 Olivier Goffart wrote:
> > > > However, it is questionable if even this works. We already rely on
> > > > the standard library ABI in QException. And most users will have
> > > > to recompile everything if they want to change standard library
> > > > anyway.
> > >
> > > std::exception is compatible between libc++ and libstdc++, so that
> > > doesn't count.
> >
> > Ok.  (But by luck... another version might not)
> 
> s/luck/design/
> 
> > Anyway, you did not answer the actual question. Are you against
> > changing the policy or not?
> 
> I am, for several reasons.
> 
> For the container types, please use the Qt ones, for API consistency and
> familiarity. I don't want to see API using std::vector, period.

Fair enough about the containers. std::string and std::list is also problematic because of https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html

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.

> 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)?

> 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++. 

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

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).

Regards

Kai