Strings and Qt

August 8, 2010

Robin Burchell wrote up something on the various string classes which are available in Qt. Unfortunately, the comment function on his blog does not work for me, so I have to respond in a separate blogpost.

Basically, Qt has two string classes. By “string”, I mean a chunk of memory which is interpreted as a set of consecutive characters. The most common string class, as Robin noted correctly, is QString, which stores the characters in UTF-16 internally.

Robin then goes on to discuss std::string. It is, however, my opinion that std::string is of limited interest for Qt developers, unless they are going to interface with STL-based libraries. This is because std::string has a better equivalent with a more precise name: QByteArray. Both std::string and QByteArray are wrappers around the traditional char* character array. As such, they are best used in scenarios which do not depend on the locale.

QString has a diverse set of conversion functions from and to QByteArray (or char*), each of which specifies its own text codec to make sense of the raw byte sequence that is QByteArray (or char*). Because most services encode in UTF-8 nowadays, UTF-8 is the default codec when a QString is initialized with a QByteArray (or a char*). When dealing with string literals in your program code, however, it is good practice to avoid the complicated UTF-8 decoding by using the simpler Latin-1 codec. This is why everyone will recommend to wrap simple string literals consisting only of ASCII characters inside a QLatin1String or a QString::fromLatin1 call instead of converting implicity (with UTF-8).

Used in the right way, the duality of QString and QByteArray can be used to distinguish locale-dependent from locale-independent values. I’m designing my APIs such that QByteArray is used whenever a value may not change between different locales (for example, a key in a configuration file) while QString denotes locale-dependent values. This way, the developer who uses my API can immediately know which literals need to be i18n()’d.

Back on topic. In case you are still wondering why QByteArray is better than std::string: It has (if done right) simple to automatic conversions to QString, it has integration with Qt’s meta object system, it has implicit sharing. That’s enough reasons for me to use it instead of std::string.

P.S. In somewhat related news, my “Certified Qt Developer” certificate was in the mail yesterday. Thanks again to Nokia for the opportunity to take the test at Tampere!


2 Responses to “Strings and Qt”

  1. Hi Stefan,

    Thanks for reading my post!

    Good notes on QByteArray – I didn’t think to mention it as I was mostly focusing on encoding-specific issues, but I think that perhaps I should have done a more generic introduction to containers – maybe next time.

    P.S. do you mind mailing me about the comment issues? I don’t know if I’ve broken something but I’ll certainly take a look – thanks 🙂


  2. Thiago Maciiera Says:

    UTF-8 is not the default for QString. The default conversion is called “fromAscii”, which doesn’t mean ASCII, but the codec you set in setCodecForCStrings. And that defaults to Latin 1.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s