GNOME v. KDE, December 2005 edition

This has been true for longer than Qt has existed, I believe: certainly it was true for years before the standardization process was complete.

Then please tell me where does std::string support Unicode?

Even for internationalized applications, std::string may be sufficient for storing, e.g., UTF-8 encodings, depending on what your application is doing with strings. nix alludes to this in his comment above. All you have to do is Google Groups for "unicode std::string", and you'll find several threads with postings from some very good C++ programmers debating the merits of using std::string for storing international strings. The consensus seems to be that as long as you're not trying to process the strings (e.g., find a substring), std::string may suffice. And depending on the implementation of your STL, std::wstring may be good enough for UCS-4 encodings with "real" string semantics.

By the way, in my original comment criticizing Qt's "QTL," I didn't mention QString as one of the offending classes. I think it's clear that for a toolkit like Qt or GTK+, you need a portable, convenient class for dealing with Unicode strings until the C++ ISO committee cleans up the internationalization mess. (Though I would prefer a strictly UTF-8 class, can't we all just switch to this particular encoding?) So I never actually complained about QString. I was objecting to boudewijn's comment that, "C++ standard string class still isn't suitable for real-world use," which is complete nonsense. Maybe it's unsuitable for a GUI toolkit -- *maybe*, I would still prefer a toolkit that's templated on string types so that I can choose the appropriate representation for my application, e.g., I don't need multi-byte strings and don't want to pay the cost of one -- but certainly not unsuitable across the board.

Where are the often needed features like toInt(), toFloat(), replace(), trimmed(), rightJustified()

I don't know what the other methods do, Boost may have similar functionality, but in any case, lack of these methods hardly makes std::string unsuitable for "real-world use." Millions of real-world applications do just fine without them.

moc provides Qt Meta-Object System. This is much more than just signal/slots. It's also dynamic properties and introspection. Those things are very useful for scripting engines or GUI builders. Please see http://doc.trolltech.com/4.1/metaobjects.html.

Regarding STL: There is nothing that prevents you from using STL instead of QTL in your Qt applications. Also you can even use the STL algorithm with the QTL containers. But a few things make QTL containers easier to use. Please see http://doc.trolltech.com/4.1/containers.html for reference.

p.s. ... which reminds me of one more thing I don't like about Qt. Passing around raw pointers is really inexcusable in modern C++ design. Passing around containers of raw pointers (ala QListWidget::selectedItems()) is even worse! Please give me reference-counted pointers, preferably boost::shared_ptr, though templating on pointer type is even better. gtkmm is slightly better than Qt in this regard, but still inconsistent (some methods return raw pointers and others do not, though maybe there's a rhyme to their reason).