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

[Ravikiran Rajagopal]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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

There's nothing preventing one from subclassing QTL code with a nonstandard 
interface. It's just common sense to try and reuse components from QTL or 
STL. Remember that there is no partial template specialization for functions; 
so, one would have to rewrite a lot of templated code to actually create a 
misleading std::vector for example.

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

You only maintain (or fix bugs) in code you understand. If you understand QTL, 
you should be able to understand STL easily; as for documentation, please see 
the link Maksim posted. Then the question boils down to whether there are 
sufficient KDE developers who understand STL. I would say yes, because STL 
based code is used *and* maintained in atleast the following directories in 
KDE CVS (I'm sure I've missed some):

arts/mcop
kdelibs/kjs
kdepim/mimelib
kdenetwork/lanbrowsing/lisa
kdegraphics/kgamma/xf86gammacfg
kdesdk/cervisia
kdesdk/poxml/antlr/src
kdevelop/lib/antlr/src
koffice/kexi/kexiDB/cql/cql/common

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. Plus, I don't 
see why preventing interoperability between QTL & STL is beneficial when 
measured against the cost of using well-understood constantly evolving 
algorithms that are widely deployed.

Regards,
Ravi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+rW35bI8Y8y0oVXcRAukZAJ94NxRN6PTrqFnj45OF8XNtgS4mOwCgif3S
dCzpJTnK0nCmRwQ92vZfkMM=
=kxEJ
-----END PGP SIGNATURE-----