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

[Guillaume Laurent]

On Tuesday 29 April 2003 18:45, George Staikos wrote:
>
>    Anybody can recompile Qt with -stl support - it's binary compatible!  We
> just don't need to recommend it.

So applications which are not in KDE CVS won't be able to use Qt's STL support 
because asking end-users to recompile Qt is not a viable option.

> If it's there, it will encourage people
> to use it.  For sure.  Without a doubt.

Everybody agrees the STL is harder to use and less well documented than Qt. Do 
you really expect that all KDE developers will get masochistic all of a 
sudden ?

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

Your catastrophism here totally undermines your point IMHO. A Plaaague will 
fall upon us if we ever allow the Evil Cursed STL ! Aaaahhh!.

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

Do you suggest one re-implements std::set<> or std::multiset<> in Qt ?

>  - STL is a big portability and maintenance problem
>
>  - 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.

You have no idea of how we abuse the STL in Rosegarden. Never been a 
performance problem, at least according to cachegrind.

> I am certain that this will eventually happen if
> STL is used. Not every KDE developer has 2GHz of compiling power.

By the time it happens, if it happens, chances are that every KDE developer 
will have 2GHz of compiling power, if not more :-).

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

Who says the STL should become a dependency ?

I'm sorry but as far as I understand, your whole point is simply that if KDE 
recommends '-stl' for compiling Qt, then every one will rush to use the STL 
in KDE CVS and horrible things will happen. I find that extremely doubtful, 
and I think you can trust KDE developers to understand such a simple 
recommandation as "compile Qt with STL support for 3rd party applications, do 
not use the STL in KDE CVS unless you really have to".

On the other hand, I don't think you can reasonably tell 3rd party developers 
that they can't rely on Qt's STL support, especially since the level of STL 
support in C++ compilers is rising, and people will expect to be able to use 
it without restriction.

Finally, Qt's "re-invention" of standard containers is a recurrent (although 
silly) argument against it. The STL support in Qt3 makes it obsolete, it 
wouldn't look good if KDE would reject for no serious reason.

-- 
				Guillaume
				http://www.telegraph-road.org