QT_NO_STL in KDE4
faure at kde.org
Wed Sep 13 17:41:35 BST 2006
On Wednesday 13 September 2006 17:35, Dirk Mueller wrote:
> On Wednesday 13 September 2006 16:56, David Faure wrote:
> > Wow that's a large difference if it's indeed only due to -DQT_NO_STL.
> > Surprising, for just a few typedefs....
> A few typedefs?
> $ cat st.h:
> #include <string>
> #include <map>
> #include <iterator>
> #include <list>
> $ g++ -c st.h -o - -E | wc -c
Ah, I see what you mean, qlist.h includes <list> for std::list<->QList conversion.
And I see now that it has changed since Qt3. In Qt3 QT_NO_STL also disabled the stl-compatible
typedefs in the Qt collection classes. But not so in Qt4 anymore, the typedefs are always there,
so STL algorithms can be used, it's just the conversion to/from STL classes that would be out
by default - which confirms the idea of having QT_NO_STL by default then, and let code
that needs it use remove_definitions(-DQT_NO_STL).
E.g. back to the initial question:
> My app uses some boost libraries and thus depends on the Qt STL support.
Does it really need conversion to/from STL classes? Isn't it enough to use the Qt containers
as the almost-stl-compatible containers they are? (almost: no reverse iterators!)
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the kde-core-devel