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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
