STL vs. Qt (Was: Google Summer of Code 2006 Project proposals)

[Vladimir Prus]

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

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.

- Volodya