From kde-core-devel Mon Apr 28 21:08:26 2003 From: Antonio Larrosa =?iso-8859-1?q?Jim=E9nez?= Date: Mon, 28 Apr 2003 21:08:26 +0000 To: kde-core-devel Subject: Re: Reason for -no-stl in qt-copy configure recommendation? X-MARC-Message: https://marc.info/?l=kde-core-devel&m=105156655921820 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::allocator > >::erase(std::_Rb_tree_iterator, std::pair&, std::pair*>*)' /usr/include/g++/bits/stl_map.h:284: candidates are: void std::map<_Key, _Tp, _Compare, _Alloc>::erase(std::_Rb_tree<_Key, std::pair, std::_Select1st >, _Compare, _Alloc>::iterator) [with _Key = std::string, _Tp = std::string, _Compare = std::less, _Alloc = std::allocator >] /usr/include/g++/bits/stl_map.h:297: std::_Rb_tree<_Key, std::pair, std::_Select1st >, _Compare, _Alloc>::size_type std::map<_Key, _Tp, _Compare, _Alloc>::erase(const _Key&) [with _Key = std::string, _Tp = std::string, _Compare = std::less, _Alloc = std::allocator >] /usr/include/g++/bits/stl_map.h:310: void std::map<_Key, _Tp, _Compare, _Alloc>::erase(std::_Rb_tree<_Key, std::pair, std::_Select1st >, _Compare, _Alloc>::iterator, std::_Rb_tree<_Key, std::pair, std::_Select1st >, _Compare, _Alloc>::iterator) [with _Key = std::string, _Tp = std::string, _Compare = std::less, _Alloc = std::allocator >] Don't continue reading and try to guess what was the problem. 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::remove(QString*)' /usr/lib/qt3-head/include/qdict.h:68: candidates are: bool QDict::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. > > We are not preventing interoperability. it is a question of whether > KDE CVS, "KDE as a project", should be writing STL code in KDE CVS. We > have standardized on Qt, not glib, not STL. > > > I am going to state this one last time. If people do not obey the > standardizations, then I intend to save myself huge amounts of > development time by removing KOpenSSL, linking statically to libcrypto > and libssl (dynamically is no good because of BIC issues), and using > OpenSSL's container toolkit. Then I can junk all of the extra work I > did (thousands of lines of code), and KDE apps can regain all that RSS > that I spent so much time to remove. My life will be easier, KDE will > be slower, and no-one will be able to understand my code without a good > chunk of time spent reading OpenSSL headers and docs. Big deal. > > It's not fair that most people can follow the coding guidelines and > principles, but one or two can flagrantly disregard them and cause extra > problems and performance hits for others simply to save themselves 5 > lines of code. Amen ! -- Antonio Larrosa Jimenez KDE developer - larrosa@kde.org http://developer.kde.org/~larrosa/ Try not to have a good time...This is supposed to be educational --C.Schulz