Re: ustring::compose and win32

[Chris Vine <chris cvine freeserve co uk>]

On Thu, 19 May 2011 21:00:12 +0200
Bastien Durel <bastien durel org> 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