On Thu, 19 May 2011 21:00:12 +0200 Bastien Durel <[email protected]> wrote: > I know that, but I cannot figure why an integer-to-string conversion > inside ustring fails: there's nothing to do with the OS. > I use UTF-8 anywhere in the program, loading data from an UTF-8 > database, and it renders well ; including the π or ™ characters. > > I digged into source code, and saw ustring::compose uses > std::wostringstream (as GLIBMM_HAVE_WIDE_STREAM is defined) to > "stringify" parameters, and then uses g_utf16_to_utf8 or g_convert to > convert data back to UTF-8. > g_convert is used as SIZEOF_WCHAR_T seams not to be defined. > > g_utf16_to_utf8 works (out-of-the box), but not g_convert("UTF-8", > "WCHAR_T"). > > The question is now : "how to make g_convert work?"
I guess you are looking at the code in ustring::FormatStream::to_string() in ustring.cc. On unix-like systems, whether g_convert() supports a WCHAR_T target depends on whether iconv() supports it. glibc's iconv() does, and normally on unix-like systems this would be mapped to UTF-32. It looks as if whatever provides the equivalent conversion support for windows does not. Two or three years ago the definition of SIZEOF_WCHAR_T was omitted when configuring glibmm for windows, I think because it caused some build problems somewhere. It looks as if the code in ustring.cc hasn't caught up with this. I guess this shows how infrequently glibmm is used under windows. I should file a bug at bugzilla. In meantime, since as far as I am aware in all windows systems sizeof(wchar_t) is in fact 2, you could patch the preprocessor conditional compilation statement so that it only tests G_OS_WIN32. Chris _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
