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

[Marcus Camen]

> > > > Perhaps antlr and cql are not the best examples, but (at least with
> > > > antlr) you have to read the source to figure out many things.
> > > > (Further, newcomers to KDE/QT development would atleast have heard of
> > > > the STL; the learning curve is not so steep for them.) Apart from
> > > > std::vector<bool>, STL code is probably of as high a quality as QTL
> > > > for most reasonable implementations.
> > >
> > >     There is no significant learning curve for Qt.  It's *trivial* in
> > > comparison to STL.  Also, you cannot talk about "most reasonable
> > > implementations".  KDE has to work and be developed on MANY platforms,
> > > not just gcc/linux.  HP-UX, AIX, Solaris, *BSD, Tru64, IRIX, for
> > > instance. Have you used STL on all of those?  I've used it on all but
> > > Tru64.  I've also used Qt on all of those but Tru64.
> >
> > I want to stress this. The degree of support for the STL is quite
> > different on different UNIX platforms. Some features are simply not
> > implemented others are buggy.
>
>  Could you be please more specific about this? What errors do you get when
> compiling some KDE code at already uses STL (listed in one mail above, e.g.
> kdesdk/cervisia)? When I asked on kde-cvs@, from your answer
> http://lists.kde.org/?l=kde-cvs&m=105155654610177&w=2 it looked like the
> compiler has problems with KDE in general, even without STL (e.g. namespace
> problems).

I don't have the non-Linux Boxes available right now (actually our software 
people do the main work right now). I will try to gather some information in 
my office the next days. But you shouldn't be worried about this KDE 
namespace stuff. This was a compiler bug which has been fixed by SGI (see 
http://lists.kde.org/?l=kde-devel&m=102647305325536&w=2).

On IRIX some c* include files are not available (cstdlib, ctime, cassert). 
Instead you have to use the usual c pendants (stdlib.h, time.h, assert.h). 
Furthermore one has use the C++ include files which don't end with *.h 
(<fstream.h> / <fstream>, etc.). Prefixing C++ calls with std:: is another 
common compile fix.
Don't ask me why this is necessary. Is this due to compiler bugs or is this 
simply C++ standard? Who knows? I am not an C++ wizard but more an admin guy.

So the use of 'vector' in KDE is not a real problem. IMHO it's just gcc 3.2 
which doesn't seems as pedantic as other compilers. You just have to take 
care about these std::, <include> vs. <include.h> like stuff.

--
Marcus