Reason for -no-stl in qt-copy configure recommendation?
Lubos Lunak
l.lunak at suse.cz
Tue Apr 29 09:48:26 BST 2003
On Monday 28 of April 2003 23:08, Antonio Larrosa Jiménez wrote:
> El Lunes, 28 de Abril de 2003 20:31, George Staikos escribió:
> > There is no significant learning curve for Qt. It's *trivial* in
> > comparison to STL. Also, you cannot talk about "most reasonable
> > implementations". KDE has to work and be developed on MANY platforms,
> > not just gcc/linux. HP-UX, AIX, Solaris, *BSD, Tru64, IRIX, for
> > instance. Have you used STL on all of those? I've used it on all but
> > Tru64. I've also used Qt on all of those but Tru64.
>
> And don't forget the different compilers on those platforms. I've been
> developing with the STL this month, and it hasn't been nice.
> See for example a "simple" error mesage from a very simple error (really
> simple) :
> a5.cpp: In function `int main(int, char**)':
> a5.cpp:18: no matching function for call to `std::map<std::string,
> std::string, std::less<std::string>, std::allocator<std::pair<const
> std::string, std::string> > >::erase(std:: Rb tree iterator<std::pair<const
> std::string, std::string>, std::pair<const std::string, std::string>&,
> std::pair<const std::string, std::string>*>*)'
[snip]
>
> Don't continue reading and try to guess what was the problem.
Yes, it's hard to guess. You somehow omitted at least a bunch of underscores,
making the above illegal C++ prototype. And BTW, the below 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?)
> Now compare that to the equivalent error with Qt :
>
> q5.cpp: In function `int main(int, char**)':
> q5.cpp:14: no matching function for call to
> `QDict<QString>::remove(QString*)' /usr/lib/qt3-head/include/qdict.h:68:
> candidates are: bool
> QDict<type>::remove(const QString&) [with type = QString]
>
> isn't it clear now?
> I don't know you, but I prefer to read the second kind of messages.
And how about this:
int main()
{
QStringList l;
l << "a" << "B" << "c" << "D" << "a" << "b" << "e" << "b";
l.sort();
QStringList::Iterator it = l.begin();
QStringList::Iterator it2 = l.begin();
if( it2 != l.end())
{
++it2;
while( it2 != l.end())
{
if( *it == *it2 )
{
++it2;
continue;
}
*it = *it2;
++it;
++it2;
}
}
while( it != l.end())
it = l.remove( it );
for( QStringList::ConstIterator it = l.begin();
it != l.end();
++it )
kdDebug() << *it << endl;
}
int main()
{
const char* const txt[] = { "a", "B", "c", "D", "a", "b", "e", "b" };
list< string > l( txt, txt + 8 );
l.sort();
l.erase( unique( l.begin(), l.end()), l.end());
for( list< string >::const_iterator it = l.begin();
it != l.end();
++it )
kdDebug() << *it << endl;
}
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.
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 (and, if STL
is really so weird as you say, why would they use it, after all?). In fact,
this is not even about using STL containers in KDE. 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.
--
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/
More information about the kde-core-devel
mailing list