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

Neil Stevens neil at qualityassistant.com
Mon Apr 28 23:05:00 BST 2003


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

On Monday April 28, 2003 11:48, André Wöbbeking wrote:
> On Monday 28 April 2003 20:31, George Staikos wrote:
> > On Monday 28 April 2003 14:07, Ravikiran Rajagopal wrote:
> > > 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.
>
> and on C++ and STL is part of C++ for many years.

That's a decision ANSI and/or ISO made about C++.  KDE can make its own 
decision independently.  Such decisions have been made in the past.  
Exceptions were once avoided, sprintf is avoided.  Minimizing use of the 
standard library would not be a new thing for KDE at all.

- -- 
Neil Stevens - neil at qualityassistant.com
"The shepherd drives the wolf from the sheep's throat, for which the
sheep thanks the shepherd as a liberator, while the wolf denounces him
for the same act as the destroyer of liberty." -- Abraham Lincoln
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+raWWf7mnligQOmERAhCVAJ9jVpPO3A+WKPXon5xOnSRGwXGjhACfQb7o
t2wpMMCx9N9s1CzrKszf2UM=
=lQM0
-----END PGP SIGNATURE-----





More information about the kde-core-devel mailing list