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

[Lubos Lunak]

On Thursday 24 of April 2003 10:30, Stephan Kulow wrote:
> On Wednesday 23 April 2003 12:11, Marc Mutz wrote:
> > Hi!
> >
> > 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?
> >
> > Can we change the recommendation -no-stl to -stl for HEAD/3.2 then,
> > please?
>
> Well, if you use it in the code, it's no longer a recommendation, it's a
> requirement then. That's exactly why we do not use it and then recommend to
> compile the lighter version

 ( Lighter? Hehe. Which of those typedefs and inline methods exactly should 
make the STL support so heavyweight? ;)  ).

 Why should be there anything wrong with requiring STL support in Qt? Just 
because TrollTech supports every Nulix-0.1 doesn't mean we should too. I 
thought it was ok to use standard C++ libs by now? And, since IIRC I saw some 
of those warnings about obsolete C++ headers, it seems we already do use them 
anyway.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/