Re: Glib::ustring tradeoffs?



Hi, Mathias,

There is of course a way to use the filenames and convert them to utf8 and back how you can see here:
#include <iostream>
#include <glibmm.h>


int main(int argc, char**argv)
{
std::string iso = "äüöß We germans love our umlauts and want to keep them";
Glib::ustring utf8        = Glib::locale_to_utf8(iso);
std::string iso_from_utf8 = Glib::locale_from_utf8(utf8);
std::cout << std::boolalpha << ( from_utf8 == iso) << std::endl;
return EXIT_SUCCESS;
}

But you can't rely on the filenames. I think it won't be a problem to convert an utf8 string to a locale string or a locale string to an utf8 string as long it keeps on the same machine and the filename won't be used on an other machine with a different locale. I don't know how Glib::utf8_to_locale or Glib::utf8_from_locale works I think it highly depends on it. Maybe there are others can suggest you anything for this.

With best regards,
Vinzenz 'evilissimo' Feenstra

Matthias Kaeppler schrieb:

Vinzenz 'evilissimo' Feenstra wrote:
> Since there is a operator std::string() in Glib::ustring you will be
> abled using everything what wants a std::string, but I don't think that
> neither  the algorithms nor boost::filesystem will work with a utf8
> encoding. So you might use locale_from_utf and locale_to_utf functions
> to convert between encodings if it possible at all.

Let's say I have a filename named "übung1.txt" (Note the umlaut--if your newsreader can display it hehe). Will this filename make trouble with std::string, or be lost/replaced when converting to Unicode?

I really really need to consider this well, because I am using a lot of convenience functions from boost::filesystem, such as path::branch_path() to retrieve the parent folder of a path. Or all the helper functions which can check for existence of a file, or those which can expand a basename to a full path... The list goes on.

If I decide to use Glib::ustring now, all these function may become unavailable (and I will have to look elsewhere for similar functionality, and I will lose a lot of time).

- Matthias

_______________________________________________
gtkmm-list mailing list
gtkmm-list gnome org
http://mail.gnome.org/mailman/listinfo/gtkmm-list







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]