gtkmmがstd::stringインターフェイスを使用していないと知ったらあなたはきっと驚くでしょう。その代わりに、Glib::ustringを使います。これは癖のない自己主張しないインターフェイスですから、実質、Glib::ustring はstd::stringであると考えて、このセクションの残りは飛ばしてしまってもかまいません。しかし、アプリケーションで英語以外の言語を使おうと思っているなら読み続けてください。

std::stringは一文字あたり8ビット使います。しかし、8ビットではアラビア語や中国語、日本語といった言語をエンコードするのに十分ではありません。現在、これらの言語をエンコードする方法は、Unicodeコンソーシアムによって明確に定められていますが、CやC++言語にはUnicodeをサポートする標準的な仕組みが提供されていません。そこで、GTK+とGNOMEではUnicodeをUTF-8を使って実装することを選択しました。Glib::ustringがそのラッパーになっています。Glib::ustringはstd::stringとほとんど全く同じインターフェイスを提供し、std::stringからの自動変換も行います。

UTF-8であることの利点の一つは、使おうと思っていないのなら無理に使う必要がないというところです。コードを一気に書き換える必要はないのです。std::stringは現在のところ7ビットASCII文字列で動作します。しかし、例えば、自分のアプリケーションを中国語にローカライズしようとすると、きっと奇妙なエラーに遭遇することでしょう。クラッシュするかもしれません。ですから、必要なのはGlib::ustringを代わりに使うことだけなのです。

UTF-8で気をつけてほしいのは、8ビットエンコーディング（ISO-8859-1など）と互換性がないということです。例えば、ドイツ語のウムラウトはASCII文字の範囲にはなく、UTF-8でエンコードするにはもう1バイト以上必要です。もしもコードに8ビット文字列リテラルが含まれているのなら、それらはUTF-8に変換しておかないといけません（例えば、バイエルン地方の挨拶 "Grüß Gott" は "Gr\xC3\xBC\xC3\x9F Gott" のようになるでしょう）。

文字列に対するCスタイルのポインタ演算や、slrlen()のような関数は避けるべきです。UTF-8では文字はそれぞれ1から6バイト必要な場合があります。ですから、ある文字の次の1バイトが別の文字であると仮定することは出来ません。Glib::ustringではこのことに気を配っていますから、バイト数ではなく文字数で考えたまま、Glib::ustring::substr()のようなメソッドを使うことができます。

この方法だとWindowsのUCS-2によるUnicodeの取り扱いと違って、文字列リテラルを処理するのに特別なコンパイラを必要としません。さらに、Unicode版の実行ファイルあるいはライブラリがASCII版のそれらと互換性がない、ということも起こりません。

Reference

UTF-8文字列リテラルの扱いに関する情報については国際化のセクションを見てください。