[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