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

[George Staikos]

On Monday 28 April 2003 13:53, Christian Loose wrote:
> >    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=arti
>cles&topic=reference)

   Or people could not be stupid about it, and implement it cleanly in Qt 
style.  If it's used in 2+ places, then it can go in kdelibs!  Go figure, 
just like widgets!

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

   That's fine.  This is out recommended compile option collection for 
developers, not what gets shipped to users through distros/packages.

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

   We already have std::vector equivalence in Qt.  What you are saying is that 
only things that cannot be done with Qt may be done with STL?  I will be 
interested to see this.

> >    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?re
>v=1.41&content-type=text/x-cvsweb-markup)

  All of that code should be cleansed.

   Ask Dirk if you don't believe me.  We both wasted enough time fixing STL 
bugs in KDE a few months ago because the author wrote the code, dumped it in 
CVS, then disappeared.  IMO code that uses STL and is not maintained should 
be reverted to pre-STL, or removed.

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