[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Reason for -no-stl in qt-copy configure recommendation?
From:       Antonio Larrosa =?iso-8859-1?q?Jim=E9nez?= <larrosa () kde ! org>
Date:       2003-04-28 21:08:26
[Download RAW message or body]

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>*>*)'
/usr/include/g++/bits/stl_map.h:284: candidates are: void std::map<_Key, _Tp,
   _Compare, _Alloc>::erase(std::_Rb_tree<_Key, std::pair<const _Key, _Tp>,
   std::_Select1st<std::pair<const _Key, _Tp> >, _Compare, _Alloc>::iterator)
   [with _Key = std::string, _Tp = std::string, _Compare =
   std::less<std::string>, _Alloc = std::allocator<std::pair<const std::string,
   std::string> >]
/usr/include/g++/bits/stl_map.h:297:                 std::_Rb_tree<_Key,
   std::pair<const _Key, _Tp>, std::_Select1st<std::pair<const _Key, _Tp> >,
   _Compare, _Alloc>::size_type std::map<_Key, _Tp, _Compare,
   _Alloc>::erase(const _Key&) [with _Key = std::string, _Tp = std::string,
   _Compare = std::less<std::string>, _Alloc = std::allocator<std::pair<const
   std::string, std::string> >]
/usr/include/g++/bits/stl_map.h:310:                 void std::map<_Key, _Tp,
   _Compare, _Alloc>::erase(std::_Rb_tree<_Key, std::pair<const _Key, _Tp>,
   std::_Select1st<std::pair<const _Key, _Tp> >, _Compare, _Alloc>::iterator,
   std::_Rb_tree<_Key, std::pair<const _Key, _Tp>,
   std::_Select1st<std::pair<const _Key, _Tp> >, _Compare, _Alloc>::iterator)
   [with _Key = std::string, _Tp = std::string, _Compare =
   std::less<std::string>, _Alloc = std::allocator<std::pair<const std::string,
   std::string> >]

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<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.

>
>    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




[prev in list] [next in list] [prev in thread] [next in thread]