On Monday 15 June 2015 17:33:35 Thiago Macieira wrote:
> On Monday 15 June 2015 17:24:39 Marc Mutz wrote:
> > Qt's binary compatibility is between Qt versions, not between toolchains,
> > and as such, I don't see a problem saying that if you change the
> > toolchain (STL (version)), then the BC guarantees are voided. That's
> > just what we have now already.
>
> 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.
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.
> [*] 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.
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.
Thanks,
Marc
--
Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
