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

[Daniel Stone]

On Mon, Apr 28, 2003 at 02:31:26PM -0400, George Staikos wrote:
>    Most likely it will be reverted from KDE CVS if it is not going to be 
> maintained properly.

I would hope that this would happen to any code; it's utterly irrelevant
to your anti-STL crusade.

> > 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 easy to write awful code in any language, any toolkit.

Using it properly takes some learning.

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

And ... ?

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

Why should "KDE as a project" not leave this up to developers'
discrection?

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

I personally see no problem with using the STL; it's there, it's
standard (hence the name!), it's not a hack, and is generally
implemented well (no problems with either GNU or SGI's implementations,
here).

Where in the KDE coding guidelines does it say "STL am teh suck"?

-- 
Daniel Stone 	     <daniel at raging.dropbear.id.au>             <dstone at kde.org>
KDE: Konquering a desktop near you - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030429/8d443d78/attachment.sig>