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

[Lubos Lunak]

On Monday 28 of April 2003 17:00, George Staikos wrote:
> On Monday 28 April 2003 04:55, Rolf Magnus wrote:
> > > > Can we change the recommendation -no-stl to -stl for HEAD/3.2 then,
> > > > please?
> > >
> > >   I don't think this is a good idea.  I foresee much more STL use as
> > > opposed to Qt use, for one. We'll be fragmenting our use of containers.
> > > If it's available to developers, I'm sure they'll use it instead.
> >
> > And that would be bad?
>
>    Using multiple container sets is bad software engineering.  I work on
> projects that use STL exclusively, and I work with projects that use Qt. 
> If i used Qt in a project that used STL, they would not accept it.  In a Qt
> commercial project I worked on, if I had used STL, they would not have
> accepted it.  It would be bad engineering.  This is no different than
> mixing in GTK and Motif widgets in KDE applications.  They're both as
> standard as Qt is.
>
>    If you allow people to use STL, you have no right to deny them to
> reimplement, say std::vector, their own way and use that.  Then you could
> have a different class with a different interface in every app/library!
>
> > If you don't want to use it, then don't, but why do
> > you want to force others?
>
>    When you write code in KDE CVS, you put the burden of maintenance on
> everyone else's shoulders.  If you write STL code, you are requiring every
> other KDE developer to use STL too, in effect, unless that code has to get
> dumped the moment you stop maintaining it sufficiently to keep it bug free
> and shippable.
>
>    Are there special cases?  yes...  Some things absolutely have to use
> other widgets/toolkits simply to be able to interface with third parties.
> nspluginviewer has to make one simple Motif call in order to load plugins.
> Do we use Motif elsewhere?  No!

 But that's because Motif is inferior to Qt (or at least most people would say 
so). I'm not sure if that can be said for STL vs QTL. I know a couple of 
cases when STL beats Qt.

 Like, say, when you need a container that doesn't require default constructor 
for the elements. Or one that can use something different than operator<() 
for comparing the elements. Or when you want to avoid the overhead of 
malloc() and want to use faster allocation (this should ring a bell to 
Maksim(?) and his attempts with Qt). I'm quite sure I knew few more, but I 
don't recall them now. Or the std::unique() case that started this all.

 I don't actually know STL much, besides playing with it, so my support for 
STL here shouldn't count that much, but when comparing STL and QTL, I see 
only two advantages of QTL: It compiles on every broken Nulix-0.1 out there, 
and its API looks simpler (which is possibly a matter of personal preference, 
and perhaps could be improved on the STL side by subclassing or writing more 
algorithms). But maybe you know more arguments for QTL that would outweight 
the cases where QTL loses?

 PS: I personally really wonder how much QTL's implicit sharing slows (yes, 
slows) things down. Too bad I don't know how to create some useful 
representative benchmark.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/