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 
        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


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 

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

Attachment: signature.asc
Description: This is a digitally signed message part.

Qt5-feedback mailing list

Reply via email to