I can't agree with this, though I do have respect for Qt. But, having to put magic macros inside all your subclasses doesn't really make things simpler... and, Qt's own libraries for doing many of the things that the STL does are mostly of the same complexity as the analogous tools in the STL.

The "magic macros" aren't a big deal; you just stick "QOBJECT" at the top of every class, it's not hard, and it's just one line (and one word). And the complexity of Qt's libraries is irrelevant; the whole point of using a toolkit like Qt is so that it hides the complexity for you and gives you tools in an easier-to-use format instead of you reinventing the wheel over and over, or getting different tools from different places, of varying quality. In the process of that, Qt (much like Boost) attempts to provide all the tools you'll need for general tasks, rather than just supplementing STL by providing lots of stuff it lacks.

Also, STL syntax is ugly and hard to work with; Qt's is a lot easier, which is another reason they replace STL's functionality with their own. (Boost, similarly, has its own style of syntax.)

(If you're referring to any macros related to the signal/slot mechanism, that's because C++ itself has no such mechanism natively so of course it's going to require extra macros and a preprocessor to provide that.)

In my opinion, with which many will probably disagree, there's nothing wrong with using STL containers in moderation if you approach it right. std::vector is good enough and fast enough in most cases if you reserve space and are judicious with allocations.

Maybe, but personally I think STL syntax is horribly ugly and not easy to read or work with, whereas Qt (at least to me) is much easier to parse, in addition to offering a lot more functionality and flexibility. (Qt has a lot more container types, for instance.)

I can't deny that - C++ templating is just plain ugly.

Doesn't Qt still bring it's own preprocessor? It did when I used it last.