GNOME v. KDE, December 2005 edition

Posted Dec 14, 2005 20:19 UTC (Wed) by nix (subscriber, #2304) [Link]

std::string does not dictate representation. That's what traits classes are for. Traits classes for UTF-8, UCS-16, and so on would not be very difficult to write.

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

Posted Dec 16, 2005 22:26 UTC (Fri) by dhess (subscriber, #7827) [Link]

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

Believe it or not, there are many, many C++ apps which do not need to be internationalized. I work on a very large (10m+ lines of code) in-house C++ application for a medium-sized, privately-held U.S. corporation, and all that Unicode strings would do for our application is a) slow it down and b) increase its memory footprint.

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

For toInt and toFloat, please see boost::lexical_cast. Its approach is much better than adding methods to your string class, because a) it's extensible to any type I can dream of, not just the ones that the Qt designers felt were important and b) I can override the conversion if needed (e.g., say I want my toFloat() to accept "+inf", or maybe I want to throw when I encounter that). QString's to* methods are non-virtual, so I'm SOL if I don't like their implementation.

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.

You're not reading what I'm saying! I don't care if moc does my dishes and takes out the garbage. I object to the requirement that I use it for my Qt application, not its convenience! gtkmm requires no such thing and I can always use moc (or any other code generation system) with a gtkmm app for all the other "good things" it does, if I choose to do so. These things should be orthogonal, not intimately tied together as they are in Qt.

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.

As far as I can tell, what you say doesn't apply to the Qt widget classes, since they're not templated. For example, if I want a list of selected items in a QListWidget, I get back a QList of QListWidgetItem *. So I don't see how I can avoid using QTL in Qt. Please correct me if I'm wrong, I would love to hear about it because this is one of my main objections to using Qt.

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