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

[Daniel Stone]

On Tue, Apr 29, 2003 at 08:03:57AM -0400, Cristian Tibirna wrote:
> On Tuesday, 29 April 2003 07:17, Daniel Stone wrote:
> > I've done a lot more STL coding than Qt in the past month or so, and I'm
> > getting to like the STL more and more, and Qt less and less. The only
> > thing Qt has going for it over STL+Boost for my usage is that it does
> > funky things with sockets (I'm not doing GUI stuff).
> 
> You can't use your personal experience as an argument.

My experience is that Qt is kind of hackish in some places (ref.
signals/slots), and that the STL does some things better, and often just
*feels* nicer (e.g. the unique algorithm).

> And KDE _is_ about writing GUIs, at which Qt is much better.

Sure. The STL gives you nothing but cout and friends. What this is
about, however, is giving you the choice to mix and match - if you
really don't like a certain part of Qt, you have the option to implement
it in STL/

> Since, more often than not, 
> supporting two libraries (that offer a nonvoid intersection of functionality) 
> at the same time in the same code isn't a joy, choosing the one who fits most 
> of the job at hand better is essential.

To the exclusivity of another? No.

The STL is already supported by roughly every C++ installation, ever. We
don't need to be "supporting" it. This is just about not dictating to
developers what they are and aren't allowed to use in the way of
standard classes.

I understand that Qt implements a lot of things, but just because it's
Qt doesn't necessarily make it better (while it's not the STL, compare
Boost's signal/slot interface to Qt's).

> Yes, STL could eventually do template 
> programming easier than Qt does in some aspects. But Qt has a host of 
> advantages which make it indispensable for KDE development, as KDE isn't at 
> all about template programming. And since it also offers ways of doing what 
> STL does (even if we would be to accept that not as well as STL), Qt should 
> be the final choice.

I'm not suggesting to dispense with Qt. At all. Ever. Not even slightly.

What I *am* suggesting, however, is that KDE programs be allowed to use
STL classes everywhere except in DCOP calls, and in public APIs where
there's no easy cast path from the equivalent Qt class. Hell, maybe not
in public APIs at all.

But we should be able to use it, no ifs and no buts about that.

-- 
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/39ef2133/attachment.sig>