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

[George Staikos]

On Monday 28 April 2003 14:07, Ravikiran Rajagopal wrote:
> >    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

   Most likely it will be reverted from KDE CVS if it is not going to be 
maintained properly.

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

   Nice for you to say, but someone has to actually make stable releases of 
KDE.

> QTL, you should be able to understand STL easily; as for documentation,
> please see the link Maksim posted.

   Sure... I use STL regularily.  In fact, I've written more STL code than Qt 
code in the past 2 weeks.

> 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):

   You cannot state that honestly, unless you know that all of those 
developers will fix bugs promptly and correctly as needed for KDE releases.

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

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

   We are not preventing interoperability.  it is a question of whether KDE 
CVS, "KDE as a project", should be writing STL code in KDE CVS.  We have 
standardized on Qt, not glib, not STL.


   I am going to state this one last time.  If people do not obey the 
standardizations, then I intend to save myself huge amounts of development 
time by removing KOpenSSL, linking statically to libcrypto and libssl 
(dynamically is no good because of BIC issues), and using OpenSSL's container 
toolkit.  Then I can junk all of the extra work I did (thousands of lines of 
code), and KDE apps can regain all that RSS that I spent so much time to 
remove.  My life will be easier, KDE will be slower, and no-one will be able 
to understand my code without a good chunk of time spent reading OpenSSL 
headers and docs.  Big deal.

   It's not fair that most people can follow the coding guidelines and 
principles, but one or two can flagrantly disregard them and cause extra 
problems and performance hits for others simply to save themselves 5 lines of 
code.

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