STL vs. Qt (Was: Google Summer of Code 2006 Project proposals)
ghost at cs.msu.su
Tue Apr 25 11:14:05 UTC 2006
On Tuesday 25 April 2006 13:00, Richard Dale wrote:
> > C++, yes, but not necessarily stl. If every kde developer was required
> > to know stl, we certainly wouldn't have as many developers. Roberto did
> > this programming in stl so he could learn it better (iirc).
> I will be writing a Ruby parser using the rpp parser, and it makes it a lot
> easier for me if it only uses Qt containers and the Qt library. I'm not
> primarily a C++ programmer, and don't like it very much. I find the Qt and
> KDE libraries about the only C++ code that a normal human, such as myself
> can work with, as they are designed for usability over 'cleverness' with
> templates. All the stl and templates stuff is far too complicated.
I fail to see how QVector in Qt4 is more usable std::vector. The only
practical difference between them is that in Qt4, the 'size' method brokenly
returns signed int ;-) I get an impression that in Qt4, interfaces of
container classes became more similar to STL classes, so the question of
which one to use is mostly issue of religion.
> If you carry Kuba's argument to its logical conclusion we shouldn't be
> using Qt signals and slots either because there is the Boost Signals
Qt signals provide dynamic binding (connecting to QObject knowing the *name*
of the signal/slot, but not having access to the definition of the concrete
class). Boost.Signals do not, so it's not exactly the same.
More information about the KDevelop-devel