STL (was: Re: kdebase/kioslave/smtp)

[Marc Mutz]

[should have gone to kde-core-devel]

On Friday 25 April 2003 15:57, Dirk Mueller wrote:
<snip>
> but there gotta be a better reason for
> mixing Qtl and STL than this tiny problem you introduced here.
<snip>

Well, I didn't encounter the non-STL-compatibility of Qt-no-stl 
containers for the first time, you know.

I agree that you can live very well w/o STL algorithms in this 
particular case. You can live without STL algorithms in a myriad of 
cases. Taken together, though, each one adds it's share of wasted 
developer's time, reduced readability and developer productivity.

Rewrite KMail's KMMainWindow::removeDuplicates() with vector<int> and 
STL algorithms and you'll see another example for where the STL would 
be nice.

I still don't see why -stl is such a big "requirement". It's on by 
default anyway. KDE compiles fine with it being on and Qt-stl is BC 
w.r.t. Qt-no-stl.

What _exactly_ is the reason for disallowing STL use in KDE? Don't tell 
me it's b/c people would need to recompile their Qt. They do it all the 
time and those tracking HEAD CVS won't even notice an additional Qt 
compile in between the KDE recompile that's constantly necessary as 
functionality is moved from modules to kdelibs.

Neither the KDE 3.{0,1} nor the KDE 3.2 RDs oppose an -stl requirement 
on Qt, so why isn't it imposed? Else: Why isn't -DQT_NO_STL added to 
configure.in.in's?

Marc

-- 
It is truly ironic that the United States, once the beacon for
promoting the principles of freedom of expression, is now
systematically infecting other countries with this dangerous public
policy choice [the DMCA] that will restrict more speech than any law
before it.    -- EFF FTAA Alert:
                 Stop Hollywood Forcing Technology Ban on 34 Countries


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030428/bb60c445/attachment.sig>