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

[George Staikos]

On Tuesday 29 April 2003 04:38, Alexander Kellett wrote:
> On Tue, Apr 29, 2003 at 10:24:41AM +0200, Stephan Kulow wrote:
> > OK. Fine. If you don't like STL, don't use it. But why do you want to
> > prevent others from using it together with Qt?
>
> for the reaoson that George has already stated more than just
> a few times. people don't stick around, and inevitably in the
> end people who wish to fix bugs in the code are going to have
> a much more difficult job if its in write-only stl than if its
> in pure qt.

  Using STL and Qt together is fine and has its use.  I just said that it 
shouldn't be done in KDE CVS.  We don't prevent people from doing it 
externally.  As far as I can tell, the main gial of the Qt support for STL is 
so that external developers can use STL based libraries and existing STL 
based code together with Qt.

   Anybody can recompile Qt with -stl support - it's binary compatible!  We 
just don't need to recommend it.  If it's there, it will encourage people to 
use it.  For sure.  Without a doubt.  Compile times will, without a doubt, 
really head for the worst.  I have a 700 line STL file here that I'm working 
on *right now* that takes *minutes* to compile on a 300MHz Linux machine with 
gcc.  It uses 3 STL containers: string, vector, queue.  Imagine what KDE 
compile times would be like if KDE used STL all the way through.  We have 
millions of lines of code.

   We don't recommend compiling Qt with SQL support and all the SQL plugins 
right?  So what?  I add them in...

   Again:

 - Qt based project - should use Qt containers.  Using multiple container sets 
is bad engineering.  Fix the container set that's used if it's broken.

 - STL as glue to existing STL libraries is of course fine!  I never argued 
this.

 - STL is a big portability and maintenance problem, and I did not see any STL 
gurus jumping up to fix the problems in the past.

 - STL is very slow to compile, and having the same code in a KDE app that 
does both QSomeTemplate<foo> and std::some_template<foo> is going to cause 
some performance penalty.  I am certain that this will eventually happen if 
STL is used.  Not every KDE developer has 2GHz of compiling power.

 - Other people have gone to great lengths to reduce dependencies and 
inconsistencies in KDE.  It is unreasonable and unfair to add such a wide 
ranging one.

   Anyways I give up.  I'm not going to keep listing these and other points 
with different wording so that they are understood.  This thread is wasting 
time and I would rather let code speak.

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