[Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

Kevin Kofler kevin.kofler at chello.at
Tue Nov 22 06:09:01 CET 2016


Marc Mutz wrote:
> People make mistakes. The difference is that, in the STL, by way of a
> larger target audience, mistakes tend to be fewer than in Qt (looked at
> qtimageformats, lately?)

That is not a fair comparison. The STL has nothing comparable to 
qtimageformats. Image decoding and encoding is necessarily a low-level byte 
crunching task, and performance-critical, even. And thus, things such as 
buffer overflows can happen. The STL just leaves you in the cold if you need 
to do any kind of image processing.

> If Qt consistently did a better job at implementing such things, the world
> might be different. But looking at the Qt containers, and the Qt image
> format plugins, I'd much rather use an external library (STL,
> lib{jpeg,png,tiff,...) that everyone else also uses, than to reinvent the
> wheel and create bugs exclusive to Qt.

Several of the decoders already use such external libraries. (The
qt5-qtimageformats distribution package I use is linked to libjasper.so.1, 
libmng.so.2, libtiff.so.5 and libwebp.so.6.) It might make sense to port the 
others to those libraries. But using an external library does not 
necessarily fix all problems. Those libraries can have security 
vulnerabilities (buffer overflows, integer overflows etc.) too. And 
sometimes, the library you chose is not or poorly maintained. And finally, 
there can also be bugs in the way the library is called in your code. Still, 
it is usually a better approach than hardcoding the format directly in Qt.

Now, if you are suggesting that all the applications should just use the 
low-level libraries directly, that is not a reasonable suggestion. Those 
libraries typically have very low-level C APIs. And most importantly, you 
need to use a different library for every single format! That is what 
higher-level abstractions such as qtimageformats are for.

        Kevin Kofler




More information about the Development mailing list