Re: [boost] [nowide] Request for interest (nowide unicode support for windows)

Subject: Re: [boost] [nowide] Request for interest (nowide unicode support for windows)
From: Beman Dawes (bdawes_at_[hidden])
Date: 2010-06-16 17:44:54

2010/6/16 Alexander Lamaison <awl03_at_[hidden]>:

> I'm saying that Filesystem v3 on Windows doesn't interpret narrow strings
> as UTF-8 by default. Â Beman said that it did...

There is a misunderstanding here. V3, like any Windows program, by
default interprets narrow strings according to the File code page. You
have to configure that yourself if you want it to be UTF-8. Since that
is a pain, and you are using Microsoft or one of the other compilers
that support wide opens, it seems easier just to convert from the
narrow string to the wide string yourself. But if you want to fool
around getting the codepage support in place, V3 should handle it
AFAIK.

>but I beg to differ. Â Here's
> what the comments say:
>
> // Â For Windows, wchar_t strings do not undergo conversion. char strings
> // Â are converted using the "ANSI" or "OEM" code pages, as determined by
> // Â the AreFileApisANSI() function, or, if a conversion argument is given,
> // Â using a conversion object modeled on std::wstring_convert.
>
> In other words "שלום.txt" would be interpreted as being in whatever
> encoding the local code page is set to and would, therefore, produce a path
> containing gibberish for most people. Â This is standard Windows behaviour
> :P
>
> Your problem is yet another step further than this. Â Assuming fs3 correctly
> converted "שלום.txt" to the UTF-16 equivalent, how do you then open a file
> using this wide-char name? Â Well, MSVC has wchar_t overloads so this works
> fine. Â You're right about glibc++/MinGW though. Â fs::fstream will fail
> there. Â Rather than introducing a nowide library, why don't we just try to
> fix this in Boost.Filesystem?

Agreed. If anyone wants to submit a patch for glibc++/MinGW that uses
the wide Windows API, that would be a better solution.

--Beman