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

[George Staikos]

On Monday 28 April 2003 04:55, Rolf Magnus wrote:
> > > Can we change the recommendation -no-stl to -stl for HEAD/3.2 then,
> > > please?
> >
> >   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.

   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!

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

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