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

[Rolf Magnus]

On Thursday 24 April 2003 14:56, George Staikos wrote:

> > What's the reason for having -no-stl in the recommended configure line
> > for Qt?
> >
> > It's breaking STL algorithms acting on Qt container classes (some
> > typedefs are omitted if QT_NO_STL is in effect).
> >
> > Since the QTL is rather limited (I'm currently needing unique()), I'd
> > really love to use the STL algorithms on Qt containers.
> >
> > Since we already use STL containers (e.g. in arts IIRC), the STL itself
> > shouldn't be a problem, should it?
>
>   Arts does a lot of things that I wouldn't do in KDE.

And using standard C++ features is one of them?

> > 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? If you don't want to use it, then don't, but why do you 
want to force others?

>  It just adds mostly unnecessary code to Qt too.

How would that be?

Btw, fron the documentation fo QValueVector, I read that this container does 
only exist to be used on obscure or ancient systems that don't have 
std::vector (that KDE probably doesn't support anyway).