On Sunday 20 November 2016 12:53:11 André Pönitz wrote: > So: If you want to argue that using GSL, and std::exception > would be beneficial for Qt, you might want to start with > making a point about the value of the current BC promise.
Right. I wasn't going to attack the BC promise on such a fundamental level, but I agree that its value is limited in a world where not even the compiler vendors can agree on a platform's C++ ABI. I just intended to indicate that with 5.0, when we dropped QT_NO_STL, but failed to take advantage of the STL containers, with 5.2, when Q_STRINGTABLE missed to be merged because it dared to use Boost (which Qt3D freely uses, now, in something called "assimp"), and now with the GSL, which promises much stronger statig type-checking because the new vocabulary types can be used to decalre intend much better, ... With each of these, and probably more, the pendulum swings more into the direction of more harm than good for Qt as a project. As a consequence, I'm advocating at least reverting the BC guarantees to their old meaning of "two versions of Qt are BC if, for a given platform, compiler, and set of dependencies, one Qt compiled against these can be replaced by the other without breaking code compiled against the former". There are so many knobs to turn that make two C++ compilates binary incompatible, from ms-compatible bitfields, fortran-compatible double alignment, to compiler and standard library versions, that for any library to try to draw through that messy jungle a line labelled "this is where Qt BC begins" is just a logically nonsensical endeavour. Sometimes, it's just better to compile separate library versions. 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, C++ and OpenGL Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development