Hi everyone I'd like to propose a change in the definition of the -no-stl flag in Qt 5, which should still be present and not be the default.
Today's definition is: "YO COMPILA' is so old that it can't deal with C++98" and it's technically a lot of NIH and aversion to STL. I'd like to change it to a more modern and embedded-friendly definition, based upon the G++ separation of its two C++ libraries: if you use -no-stl and your system has a separate libsupc++ from libstdc++, then neither Qt nor your application will not require linking to libstdc++ (how you accomplish the linking is your business, you'll probably need to change the mkspec, but once you do, it will link properly) GCC's libsupc++ contains the C++ support functions and symbols, such as: - the base typeinfos (e.g., typeid(int) and typeid(void *)) - operator new, operator new, operator delete, operator delete - hidden support functions like __cxa_throw, __cxa_guard_acquire, __cxa_vec_new, __dynamic_cast, etc. - a few types specified in the C++ language as a result of using the language constructs, like std::bad_exception and std::bad_cast Implications: 1) [remains] -fno-rtti -fno-exception are orthogonal concepts to STL. Using them or not has no impact on the use or not of STL. 2) [remains] The current requirement that STL be used in Qt inline code only remains: you must be able to link a QT_STL application with a QT_NO_STL Qt. 3) [remains but clarified] Using C++ headers that are C++ language headers is fine, like #include <new>, but also #include <limits> 4) [changed] Using STL features that expand to inline-only code or no code (like empty tag structs and typedefs) at all is also permitted without checks. I'm thinking especially of #include <iterator>. That means you may need to have the full C++ headers anyway, even if you have an embedded system where you do separate the language support library from the rest. 5) [new] No support for compilers that don't support C++98. I'm looking at you, Sun CC (without -stlport). 6) [new] Certain Qt inline features are allowed to be disabled if STL support is disabled too. I'm thinking especially of the QtAlgorithms header: the template algorithmic functions can be completely implemented in terms of wrappers around the uglier STL functions. That said, certain more useful algorithms might need non-STL implementations too, such as qStableSort. 7) [remains] Use of C++11 features is also limited by the -no-stl definition the same way that C++98 features are: if the use of the feature requires code not in libsupc++, it needs to be disabled under -no-stl. 8) [remains, corollary] Qt front-end API cannot require the use of STL. It can and should provide STL compatibility, however. Clarifying 2+4: use of C++98 STL features that are not functions, or are inline functions that only call other inline functions is permitted anywhere, under any circumstances. Use of STL features that result in non-inline function calls is allowed only in Qt inline code, such that the call ends up in the user application, not Qt. C++03, C++11 and TR1 features require extra checks. I'm just in doubt about the implications of that and 6: if we use qStableSort internally, qStableSort is implemented on top of STL and that implementation makes function calls. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list Qt5email@example.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback