Subject: Re: STL / Qt flame-war (Re: [linux-audio-dev] Audio-related widgets with Qt ?)
From: Jelle (jelle_AT_defekt.nl)
Date: Mon Sep 17 2001 - 18:02:37 EEST
On Mon, Sep 17, 2001 at 02:22:46PM +0300, Tommi Ilmonen wrote:
> >
> > I just want to mention one reason why I don't like using Qt myself,
> > not as flamebait but just to make it clear. Qt was written before the
> > Standard Template Library (STL) was reasonably standardized. As a
> > result, it contains implementations for things like lists, vectors and
> > many other container classes, that are part of the STL. For similar
>
> I guess it depends on what one is used to. I have always found STL totally
> painful, the headers are unreadable and some of the most simple operations
> take enormous amounts of effort (like removing the n:th element from a
> list).
list are not indexed by integers but by iterators. You can ++ and -- iterator
and so on.
However, lists are linked lists, not arrays, and thus can only forward and
backford access items, but not random access. If you want that you have to
use a vector.
for(list<X>::iterator i = mylist.begin(); i!=mylist.end(); i++)
mylist.erase(i)
// or acces what is in i using: (*i)
for(int i = 0; i<myvector.lentgh(); ++i)
myvector[i]
STL is much easyer to handle that lowlevel arrays and such, and it can
be quite fast as well.
> AFAIK STL lack proper unicode support, thus STL strings are not very
> useful for multilingual apps.
I'm not completely sure, but I believe STL has locales to handle this,
and std::string is designed to work with this...
> STL does have some really nice stuff, but I seldom need/use it anyhow.
THat is a shame, the STL is really very practical.
Also, it's unlikely that you will write are more efficient/complete custom
version of anything in the STL. It's really very versitile.
> At any rate, I find the question of containers is not very important. Qt
> API usually hides the containers from the application developers
> (QString and QStringList are some of the exceptions) so app developers
> are free to use what-ever containers they like -> I do not see a conflict
> between STL and Qt (since std::string is useless from my perspective
> anyhow and strings are the only really obvious place where one is better
> off using one standard only).
At some point you are going to feed a widget a list or a string and it would
be neat if that is the same one you use in the rest of your code.
It really sucks when you need to write conversion routines to go from
STL to wxString, qtString etc..
> Now: let me tell why I do not use GTK.
>
> After getting sick with Motif, Tck/Tk, OTcl/Tk and wxWindows I decided
> that: "Heck this GTK looks really cool, I think I'll write i Gimp plugin
> so I can test how it fits me". I copied one example plugin. I compiled it.
> Great, it worked. I modified the plugin. Then it crashed. I reversed the
> modifications. Then it worked. Then I tried another modification. And it
> crashed. Then I repeated the modify->crash cycle with random success for
> a few hundred times. Then I decided that enough is enough and went over to
> Qt instead. I believe Qt has cost me fewer crashes in two years than GTK
> in a few days. This -- of course -- proves nothing besides the fact that
> GTK is not the idel toolkit for *me*.
Hmm. OK. You probably did something wrong ;)
BTW:
Am I the only one who has problems with Qt having it own custom drawn
widgets? wxWindows uses native GTK AFAIK and native Win32.
For that reason alone I would already pick wxWindows over Qt, since Qt looks
really unprofessional (I should say alien actually) under Win32. Plus it
seems that doing it yourself instead of using system native widgets imposes
a lot over useless overhead.
Cheers,
jelle.
-- defekt
This archive was generated by hypermail 2b28 : Mon Sep 17 2001 - 17:05:06 EEST