[Development] Basing Qt Creator Coding Style on C++ Core Guidelines?
Marc Mutz
marc.mutz at kdab.com
Sun Nov 20 19:49:09 CET 2016
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.mutz at 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
More information about the Development
mailing list