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

[Marc Mutz]

On Tuesday 29 April 2003 18:45, George Staikos wrote:
<snip>
> As far as I can tell, the main gial of the Qt
> support for STL is so that external developers can use STL based
> libraries and existing STL based code together with Qt.

Reading the QTL docs ("If a suitable STL implementation is not available 
on all your target platforms, the QTL can be used instead.") I get the 
impression that the QTL is a hack, there to bring minimal STL 
functionality to those poor platforms that lack a working STL.

<snip>
>    Again:
>
>  - Qt based project - should use Qt containers.  Using multiple
> container sets is bad engineering.  Fix the container set that's used
> if it's broken.
<snip>

Read my lips: This thread is about the STL _a_l_g_o_r_i_t_h_m_s_ acting 
on _Q_t_ containers. Qt-stl vs. Qt-no-stl has _n_o_ (I repeat: _n_o_) 
impact on STL container usage whatsoever.

>  - STL is very slow to compile, and having the same code in a KDE app
> that does both QSomeTemplate<foo> and std::some_template<foo> is
> going to cause some performance penalty.  I am certain that this will
> eventually happen if STL is used.  Not every KDE developer has 2GHz
> of compiling power.
<snip>

Adding -DQT_NO_STL by default to configure.in.in's gets rid of _a_n_y_ 
slow compile time due to STL includes unless they are needed by an 
app/file.

Marc

-- 
If this were a dictatorship, it'd be a heck of a lot easier...just as
long as I'm the dictator...
-- George W. Bush, Washington, DC, Dec 18, 2000,
   during his first trip to Washington as President-Elect
-------------- 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/20030429/913c6c09/attachment.sig>