Glib::ustring
You might be surprised to learn that gtkmm doesn't use std::string in its interfaces. Instead it uses Glib::ustring, which is so similar and unobtrusive that you could actually pretend that each Glib::ustring is a std::string and ignore the rest of this section. But read on if you want to use languages other than English in your application.
std::string uses 8 bits per character, but 8 bits aren't enough to encode languages such as Arabic, Chinese, and Japanese. Although the encodings for these languages have been specified by the Unicode Consortium, the C and C++ languages do not yet provide any standardised Unicode support for UTF-8 encoding. GTK and GNOME chose to implement Unicode using UTF-8, and that's what is wrapped by Glib::ustring. It provides almost exactly the same interface as std::string, along with automatic conversions to and from std::string.
Um dos benefícios do UTF-8 é que você não precisa usá-lo a menos que queira, então não precisa mexer no seu código todo de uma vez. std::string funcionará também com textos ASCII 7 bits. Porém, quando você tentar fazer a localização do seu aplicativo para idiomas como chinês, por exemplo, você comerçará a ver uns erros estranhos, e possivelmente uns travamentos. Então, tudo que você precisa fazer é começar a usar Glib::ustring no lugar.
Note que UTF-8 não é compatível com codificações de 8 bits como ISO-8859-1. Por exemplo, os tremas alemães (umlaut) não estão na faixa ASCII e precisam de mais que 1 byte na codificação UTF-8. Se seu código contém textos constantes em 8 bits, você tem que convertê-los para UTF-8 (exemplo: o cumprimento da Bavária "Grüß Gott" seria "Gr\xC3\xBC\xC3\x9F Gott").
Você deveria evitar aritmética de ponteiros no estilo C e funções como strlen(). Em UTF-8, cada caractere pode precisar em algum lugar de 1 a 6 bytes, então não é possível assumir que o próximo byte é outro caractere. Glib::ustring se preocupa com esses detalhes para você para que possa usar métodos tais como Glib::ustring::substr() enquanto ainda raciocina em termos de caracteres em vez de bytes.
Ao contrário da solução Unicode UCS-2 do Windows, ele não exige quaisquer opções especiais do compilador para processar textos contantes, além de não gerar executáveis e biblioteca Unicode que sejam incompatíveis com os em ASCII.
Veja a seção Internacionalização para informações sobre como fornecer textos constantes em UTF-8.