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

[George Staikos]

On Monday 28 April 2003 14:52, Lubos Lunak wrote:
> > >  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.

  It was just an ad-hoc example!

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

   Remember kde-qt-addons?

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

   Last I checked, KDE followed a naming guideline, for one.  For two, I would 
hope it's not a direct copy of the code from STL.

>  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

   I agree.  But then we can't easily enforce no-stl too.  That's only 
"recommended".  You're welcome to not follow that.  I build my Qt with all 
kinds of parameters not listed there.

> is not going to cost more than moving it to Qt. If you don't want STL to be

   There are more costs than just the actual binary size/memory size/run time.  
There are, for instance, costs involved in:
	- Compile time	(STL is much slower to compile, without a doubt)
	- Portability	(STL is definitely less portable, ironically)
	- Diagnosability of problems	(ever seen STL error messages - especially 
non-gcc?)
	- Developer time lost to maintenance of others' STL code

   These are no less significant.

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

   No, I suggest to enhance Qt where it is seen to be inadequate.

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

   Yes it takes experimentation.  Valgrind/cachegrind would probably help 
(that's what I used, along with counters I placed in the src).

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