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

[Lubos Lunak]

On Monday 28 of April 2003 20:12, George Staikos wrote:
> 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...

 Since when is saying that something is better than something else 
'nitpicking'? Saying that STL is better than QTL is may be wrong, but I don't 
think it's 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.

 libkdetakenfromstandardlibraries? That's silly. I thought KDE originally 
started as the "we don't suffer from NIH" project.

 Moreover, how is copying the code from elsewhere to Qt/KDE and using it from 
there, instead of using it from wherever it originally came from, supposed to 
make any difference? Will renaming std::unique to qUnique() make it generate 
only half CPU instructions?

 With Marc's QT_NO_STL suggestion, there shouldn't be (no, I mean there won't 
be) any overhead for enabling STL support in Qt, unless the STL code will be 
used. Using parts of STL when Qt doesn't provide required features is not 
going to cost more than moving it to Qt. If you don't want STL to be used in 
KDE at all, you could try arguing about not being portable enough yet, or 
similar reasonable arguments, but suggesting to move part of the language's 
standard library to Qt/KDE, when the only result of the move will be the fact 
that it was moved? That's the most absurd case of NIH I've ever seen.

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

 I think we copy containers so rarely that profiling the app and making sure 
to avoid too much copying if needed wouldn't be that much work (besides 
QString, where it would be really too cumbersome). Hard to say based on 
theory though. I'll have to play with this some day. Not that this really 
matters in this discussion.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/