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

[Marc Mutz]

On Monday 15 June 2015 11:49:40 Olivier Goffart wrote:
> On Friday 12. June 2015 14:42:44 Thiago Macieira wrote:
> > On Friday 12 June 2015 18:58:59 Marc Mutz wrote:
> > > On Friday 12 June 2015 16:37:15 Thiago Macieira wrote:
> > > > On Friday 12 June 2015 12:12:17 Olivier Goffart wrote:
> > > > > Which mean using things like std::function, std::unique_ptr, in our
> > > > > ABI.
> > > > > Should we allow that?
> > > > 
> > > > The problem is deciding between std::function and std::__1::function.
> > > 
> > > Is __1 now standard? Or just a placeholder for what Clang's libc++
> > > uses?
> > 
> > It's what libc++ uses, which is the real problem. For as long as there
> > are systems where you can opt into libstdc++ or libc++, we should avoid
> > hardcoding one or the other.
> 
> We are not hard coding one. The compiler selects one.
> 
> Now, that would mean that we break binary compatibility when the user
> switches the standard library. The question is whether we want to support
> this.

For as long as Qt existed, on Windows you could not link debug and release 
versions mixed, because memory allocated in the application (new QWidget) is 
deleted inside Qt (~QWidget).

So, we actually don't have binary compatibility in the sense that you can link 
Qt into any C++ project, regardless of how and with which compiler Qt or the 
project was built (there are C++ libraries that can do this, they funnel 
everything through a C API and reconstruct a header-only C++ API on top of 
that, much like you'd do with any other language binding, IIRC, it was in 
Lippincott's talk last year (https://www.youtube.com/watch?v=3ZO0V4Prefc)).

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.

IoW: Before we continue to ban STL types from the API because of BC reasons, 
we first need to fix the problem with mixed debug/release builds on Windows 
(e.g. by stuffing every heap-allocated object that isn't born and dies in the 
same library, into a shared_ptr, whose custom deleter takes care of calling 
the right delete version). OTOH, if we're not fixing that issue, there's no 
point in banning STL types from the API, at least not with the BC argument.

Thanks,
Marc

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