Reason for -no-stl in qt-copy configure recommendation?

[Marc Mutz]

On Tuesday 29 April 2003 14:03, Cristian Tibirna wrote:
<snip>
> And KDE _is_
> about writing GUIs,

Most of kio_smtp is about writing GUIs?

> at which Qt is much better. Since, more often
> than not, supporting two libraries (that offer a nonvoid intersection
> of functionality) at the same time in the same code isn't a joy,
> choosing the one who fits most of the job at hand better is
> essential.

And the STL fits better here. And _again_: It is not at all about using 
STL containers in KDE code (people do that already and Qt-no-stl vs. 
Qt-stl is completely independent of that). It is about bringing the Qt 
and the STL world nearer together by making the Qt containers work with 
STL algorithms.

-no-stl:
 o does _not_ prevent people from using STL containers and STL
   algorithms,
 o _does_ prevent people from using STL algorithms with Qt containers.

-stl:
  o does _not_ prevent people from using Qt containers and QTL
  o _does_ make it possible to use STL algorithms with Qt containers.

So, to summarize:
  -no-stl doesn't discourage STL container use, it _en_courages it,
   b/c a needed STL algorithm not available in the QTL does not work
   with Qt-no-stl, so you have to change the container class.
  -stl does not encourage STL container use any more than -no-stl
   already does; it _en_courages sticking to Qt containers, b/c a needed
   STL algorithm not in the QTL _does_ work with Qt-stl, so don't have
   to change the container class.

Marc

-- 
Saddam's shoes left up there [...] big shoes to fill for anyone [...]
 -- Nic Robertson, CNN,
    on toppling of Saddam Hussein stature in Paradise Square, Baghdad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030429/3bfd156d/attachment.sig>