[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: QT_NO_STL in KDE4
From:       David Faure <faure () kde ! org>
Date:       2006-09-13 16:41:35
Message-ID: 200609131841.36360.faure () kde ! org
[Download RAW message or body]

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

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@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
[prev in list] [next in list] [prev in thread] [next in thread]