Reason for -no-stl in qt-copy configure recommendation?
Daniel Stone
dstone at kde.org
Tue Apr 29 12:22:32 BST 2003
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>
More information about the kde-core-devel
mailing list