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

[Christian Loose]

Am Montag, 28. April 2003 17:00 schrieb George Staikos:
> On Monday 28 April 2003 04:55, Rolf Magnus wrote:
[snip]
> > >
> > >   I don't think this is a good idea.  I foresee much more STL use as
> > > opposed to Qt use, for one. We'll be fragmenting our use of containers.
> > > If it's available to developers, I'm sure they'll use it instead.
> >
> > And that would be bad?
>
>    Using multiple container sets is bad software engineering.  I work on
> projects that use STL exclusively, and I work with projects that use Qt. 
> If i used Qt in a project that used STL, they would not accept it.  In a Qt
> commercial project I worked on, if I had used STL, they would not have
> accepted it.  It would be bad engineering.  This is no different than
> mixing in GTK and Motif widgets in KDE applications.  They're both as
> standard as Qt is.
>

But the -no-stl option doesn't prevent you to use the STL. I just prevents the 
usage of QTL containers with STL algorithms and this leads IMHO to code 
duplication or hand-written loops.
(http://www.cuj.com/reference/articles/2001/0110/0110b/0110b.htm?topic=articles&topic=reference)

And it also pratically prevents third-party developers to use QTL with STL 
algorithms because otherwise they would have to tell their userbase to 
recompile their Qt.

>    If you allow people to use STL, you have no right to deny them to
> reimplement, say std::vector, their own way and use that.  Then you could
> have a different class with a different interface in every app/library!

I don't understand. IMHO it's something very different to say you can't use a 
part of the language (here: STL) or don't reimplement stuff that already 
exists as part of the language (STL) or in our base library (QTL).

>
> > If you don't want to use it, then don't, but why do
> > you want to force others?
>
>    When you write code in KDE CVS, you put the burden of maintenance on
> everyone else's shoulders.  If you write STL code, you are requiring every
> other KDE developer to use STL too, in effect, unless that code has to get
> dumped the moment you stop maintaining it sufficiently to keep it bug free
> and shippable.
>
>    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!

I fear your objection comes too late. If I followed kde-cvs correctly there is 
already code that utilizes STL in KDE CVS.
(http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdesdk/cervisia/updateview.cpp?rev=1.41&content-type=text/x-cvsweb-markup)

Christian