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

[Antonio Larrosa Jiménez]

El Martes, 29 de Abril de 2003 10:48, Lubos Lunak escribió:
>
>  Yes, it's hard to guess. You somehow omitted at least a bunch of
> underscores, making the above illegal C++ prototype.

I copied the errors line by line (my KMail hangs when copying many lines at 
once), but I copied all the lines.

> is not error message from equivalent Qt code. You passed QString pointer
> in the example below, and iterator pointer in the example above (how did
> you actually manage to get a pointer to an iterator?)

The problem with the stl code was that I wrote
map.erase(&it);
instead of
map.erase(it);

And the problem with the Qt code was that I wrote
dict.remove(&s);
instead of
dict.remove(s);

both problems are passing a pointer to a variable instead of the variable 
of the type the API expects, so that's why I called them "equivalent". 
They're not exactly equivalent as QDict doesn't have a remove method with 
an iterator parameter, but if there were, you know the error message would 
be similar.

Of course, that was done in purpose just to show equivalent compiler 
errors.

>  I needed about half the time to write the latter, and unlike the first
> one, it works. Moreover, the difference between reading the first and
> second one is similar to reading your two error messages.

Yep, I see. But the only difference is that STL has a unique algorithm. 
Nobody prevents anyone to implement that in the next Qt version or in 
kdecore (kde-qt-addon, whatever), and that way we would have a unique (how 
ironic :) ) naming scheme and homogeneous API, instead of a fragmented 
one.

>
>
>  But you're missing the basic point. This is not about forcing everybody
> to use STL. It is not even about encouraging everybody to use STL

Thanks god :-)

> (and, if STL is really so weird as you say, why would they use it, after
> all?)

Yes, I also wonder that :)

> In fact, this is not even about using STL containers in KDE.

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.

> This
> all started as using STL _algorithms_ in KDE, and requiring Qt support
> for it. As far as I can say, that's all Marc wants. And unless somebody
> can show STL algorithms are too unportable for use in KDE, there's no
> other good reason for forbidding it.

If there's a complex algorithm that nobody wants to mantain in a KDE-way 
(naming scheme, Qt containers, etc.) then I suppose it's ok to use that 
algorithm . The question is, is there such algorithm ? Because I don't 
think a simple unique implementation is enough to force everyone to 
compile Qt with -stl . Also, I'm sure there will be a unique() 
implementation in Qt in the next release.

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?

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.

Greetings,

--
Antonio Larrosa Jimenez
KDE developer - larrosa at kde.org
http://developer.kde.org/~larrosa/
C programs should be indented six feet downward and covered with 
dirt--BP.Hought