[Development] Notes on QtCore session @ QCS2016

[Marc Mutz]

On Tuesday 06 September 2016 02:02:50 Thiago Macieira wrote:
> > > * C++11 Standard Library compatibility list
> > >
> > > 
> > >     * no volunteers yet
> >
> > 
> >
> > Is this a matter of converting this documented into qdoc?
> >
> > 
> >
> > https://codereview.qt-project.org/#/c/142782/
> 
> We decided to make a QUIP out of this, in a later session. Stay tuned.

ENOABBREV

> > > * C++ ABI
> > >
> > > 
> > >     * libstdc++ still breaking compatibility in std::function
> > >     * not now, revisit in a year or two
> >
> > 
> >
> > There hasn't been time to discuss this at QtCon, but I'd say we should
> > not spend another year before revisiting this at the next QtCS: do we
> > really care about C++ ABI compatibility? What other C++ libraries are
> > doing this? Do users really expect to swap out standard library
> > implementations without the need of recompiling libraries and
> > applications that use them? Or is it an artificial problem we're
> > imposing on ourselves?
> 
> I think there was enough time to discuss it, we did discuss it, and we 
> concluded that it's still important enough that we don't want to depend on
> the  ABI right now. In fact, given that libstdc++ is breaking ABI across
> its own versions, it's not even a problem of libstdc++ vc libc++
> compatibility (which is also still broken in all Linux distros I've
> seen)..

The issue I see here is that the Qt BC rules are leaking. They no longer apply 
to separate Qt versions compiled with the same compiler and options (incl. 
that of which std implementation to compile against), which is how we 
understood the BC guarantee.

Instead, since some indeterminable (to me) time in the not too distant past, 
an entirely *arbitrary* selection of options is now _included_ in the BC 
guarantee, incl. the one of std library implementation, but most notably *not* 
release/debug on Windows, even though that would be just as possible, and more 
desireable (there are no two std impls for MSVC). It is being argued that this 
is a compatibility that was provided by Qt versions before, but that's a smoke 
screen: a) If you never used the types in the API, it's trivial to make that 
particular guarantee and b) it falls apart as soon as a user is using Qt API 
(which exists!) that uses std types, making it all just theoretical.

IMO it plain *isn't* Qt jobs to provide the user with that compatibility. 
That's the job of the *compiler vendors*.

It feels like the BC leak is allowed to leak just enough to use the std 
implementation incompatibilities as an excuse to keep std types out of the Qt 
ABI when equally desireable compiler options, foremost debug/release, are not 
included in the guarantee.

That's an arbitrary distinction and Qt should stop trying to provide more 
compatibility than the compiler vendors themselves are willing to give.

Thanks,
Marc

> The "a year or two" revisit is to check how relevant the breakages that we
> are  currently aware of are, at that time. If they are safely in the past
> and don't affect much, and if GCC folks have stopped playing with the
> voltage in the power switches, we can reconsider.
> 
> PS: QCS discussions are proposals. They become decisions once the ML agrees
> on  it.
> 
> PPS: those decisions will be documented as QUIPs.

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts