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

[George Staikos]

On Monday 28 April 2003 13:12, Lubos Lunak wrote:
> >    Are there special cases?  yes...  Some things absolutely have to use
> > other widgets/toolkits simply to be able to interface with third parties.
> > nspluginviewer has to make one simple Motif call in order to load
> > plugins. Do we use Motif elsewhere?  No!
>
>  But that's because Motif is inferior to Qt (or at least most people would
> say so). I'm not sure if that can be said for STL vs QTL. I know a couple
> of cases when STL beats Qt.

   Nitpicking...

>  Like, say, when you need a container that doesn't require default
> constructor for the elements. Or one that can use something different than
> operator<() for comparing the elements. Or when you want to avoid the
> overhead of malloc() and want to use faster allocation (this should ring a
> bell to Maksim(?) and his attempts with Qt). I'm quite sure I knew few
> more, but I don't recall them now. Or the std::unique() case that started
> this all.
>
>  I don't actually know STL much, besides playing with it, so my support for
> STL here shouldn't count that much, but when comparing STL and QTL, I see
> only two advantages of QTL: It compiles on every broken Nulix-0.1 out
> there, and its API looks simpler (which is possibly a matter of personal
> preference, and perhaps could be improved on the STL side by subclassing or
> writing more algorithms). But maybe you know more arguments for QTL that
> would outweight the cases where QTL loses?

   The fact that we use Qt already.  If STL has something that Qt does not, 
either implement it and send it to TT, or create an alternative and put it in 
kdelibs.  Make it follow KDE coding and naming conventions.

>  PS: I personally really wonder how much QTL's implicit sharing slows (yes,
> slows) things down. Too bad I don't know how to create some useful
> representative benchmark.

    It can in some instances, yes.  In other instances it really speeds things 
up.  When I wrote an interpreter last year I had to write my own toolkit to 
go with it.  Adding implicit sharing gave huge performance boosts.  There 
were some cases where there was a loss, but they were really marginal.

-- 
George Staikos
KDE Developer					http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/