[Development] QtCS: Notes from Modern C++ session

[Thiago Macieira]

On Monday 15 June 2015 22:12:46 Marc Mutz wrote:
> > I disagree. I understand what you said, but right now it is possible to
> > switch  from libstdc++ to libc++ with no ill effects[*]. So the question
> > is should be asked the other way around: do we knowingly remove this
> > currently-working ability?
> 
> On Solaris, back when I still used it, you could switch between the
> RougeWave- based STL, which was essentially frozen in the mid-90s, and
> stlport, which could compile Boost. The two STLs were both binary
> incompatible. The correct solution for this is to provide
> differently-compiled Qt versions, one for each STL.

Correct, but RWstl was not designed to be interoperable with libstdc++. libc++ 
was. It can be specifically configured to work in a separate (inline) namespace 
and it will share the base C++ ABI with libstdc++ (libsupc++).

> But let's take a step back, and review: With Windows out of the picture,
> because it isn't BC with itself, and OS X probably having only one STL,
> which on top is versioned with inline namespaces, that leaves the ability
> to switch between stdlibc++ and libc++, which no other C++ library
> supports, incl., AFAICT, the KDE ones.

Right, that's only between libstdc++ and libc++. The question is which OS that 
is relevant for:

a) OS X
b) Linux distributions that properly compile libc++ [*]
c) BSDs that have switched to Clang as the main compiler (e.g, FreeBSD)

> > [*] provided, of course, that the two share their base C++ ABI, which some
> > Linux distros have not yet learned to do.
> 
> ...and that not even works on all distributions.
> 
> A few years ago, there even wasn't a libc++ to make this argument.

A few years ago, our argument was different: we had the -no-stl option. During 
Qt 3 times, that meant binary incompatible builds of Qt. For Qt 4, someone 
made it so that the two builds were compatible -- whether that was intentional 
or accidental, I don't know (that was before my time). What I did ensure was 
that we made that official.

That proved beneficial when Apple decided to create libc++.

> I find this use-case of interchangable std C++ libraries far-fetched ("an
> den Haaren herbeigezogen", for those of you who know German) and not really
> worth pursuing, because it's basically a) the libc++/stdlibc++ developer's
> job to make the two interchangeable, and b) failing that, the distro's and,
> more importantly, the alternative is for us to continue to castrate
> ourselves to a life of poorly re-implemented copies of std:: functionality,
> and reduced interop with the myriad of *other* C++ libraries, both of which
> affects *all* platforms and not just the one that doesn't really need our
> help, because it's doing an excellent job of installed-software management
> already, unlike the others.

It's the same reason why we keep 32-bit OS X builds working: some people using 
Qt still need to link against proprietary libraries that are using the "wrong" 
options.

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