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

[Daniel Stone]

On Tue, Apr 29, 2003 at 12:15:06PM +0200, Antonio Larrosa Jim?nez wrote:
> Have a look at kcron, karm, and others (and look also the number of commits 
> on those apps in the last months (years?) ). Now look the way they use the 
> STL, they don't need anything special, just simple uses of containers and 
> such things that could be done perfectly with Qt.

If they prefer the STL, and they use it and it works, why bother them?

> Btw, (and I know that you're not talking about that and I'm changing a bit 
> the topic but I want to point this out) even if it's just a single user 
> that wants to use the STL in an application (not a library) there's a 
> problem of fragmentation/interoperability. Can you make DCOP calls with a 
> vector<int> argument?

If someone was doing DCOP calls, I'd hope they were using the standard,
well-defined DCOP classes.

> Of course everyone is free to use what they want in their code, but I think 
> if we allow to use STL algorithms with Qt containers, we should make clear 
> that we recommend against using the STL types when there's a Qt 
> equivalent. I wonder how difficult would be separate Qt's configure 
> options to make Qt accept STL algorithms, and to make it accept STL data 
> types.

s/recommend/suggest/.

People might prefer STL because it looks/works better.

-- 
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/7850bcb0/attachment.sig>