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