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

[Olivier Goffart]

On Monday 15. June 2015 17:24:39 Marc Mutz wrote:
> 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.

The situation on Windows and the situation on Unix are different.
On windows binary compatibility is not kept accross toolchain.
But on Linux it is (mostly)

On Unix: Clang and GCC build are compatible, C++03/C++11/C++14 builds are 
compatible. Debug/release build are compatible, libstdcpp and libcpp builds 
are currently compatible. Exceptions/-fno-exceptions build are supposed to be 
compatibles. And you can mix and match.

-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org