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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
