Subject: Re: [boost] [nowide] Request for interest (nowide unicode support for windows)
From: Alexander Lamaison (awl03_at_[hidden])
Date: 2010-06-16 16:57:44
> On Wed, 16 Jun 2010 12:50:19 -0700 (PDT), Artyom wrote:
> I think that this can be fixed (the way I fixed it in nowide
> implementing fstreambuf over stdio+_wfopen)
> But this is one particular problem.
> There are more. What about filesystem::remove and others?
> From what I see in the code, it supports only path and not wpath
Really? I doubt that. In FSv2 it takes a template path:
template <class Path>
bool remove(const Path& p, system::error_code & ec = singular );
This delegates to RemoveFileA if passed a path and RemoveFileW if passed a
wpath. glibc++/MinGW presumably uses the posix_remove API so this does,
again, suffer from the problem. We could work around it in boost though I
can't help but feel this is a MinGW problem: if it wants to work the
windows way is should provide wide APIs as well, if it wants to pretend
it's POSIX is should interpret narrow strings as UTF-8.
> When I develop cross platform applications I have following options
> for operating of files.
> For example when I want to remove, rename, create a file
> in a program writing cross platform applications, writing
> using standard platform independent C++, Writing for POSIX operating
> systems and for MS Windows.
> OS \ Str | std::string | std::wstring |
> Std C++ | Ok | Not Defined!
> POSIX | Ok | Not Defined!
> WinAPI | Not UTF-8 | Ok
> What I can see. I need either use wide strings that works only on Windows
> but require me to convert to other encoding for operations on files.
> Or I may use normal strings as standard requires and have problems
> with Windows as it is not fully supported.
We could potentially fix this in Filesystem v3 if it interpreted incoming
narrow strings as UTF-8. Then you could create a 'path' using whichever
type of string you like and the boost::filesystem functions would 'just
work' (ok, issues with MinGW but nothing we can't work around by
incorporating your code).
> So far? Why? Why do you need all this if you can just
> create a tiny layer that makes Window support UTF-8 code page
> by converting std::string to std::wstring and calling appropriate
Yep, that's pretty much what I'm saying.
> - Introducing boost::filesystem::wpath does not help as
> it meaningless on other OSes.
It's gone in v3.
> So... Just create an API that is friendly to UTF-8 strings and
> forget about this hell.
+1 from me with one modification: don't prevent using wide path on Windows.
Often you will need to pass a wide path that you get from somewhere else
and it would be a pain if we had to convert these to UTF-8 manually.
> But from what I see this will never happen in Boost as it is too
> Windows centric, and Windows is too ignorant to basic programmers
> needs who want to write a portable programs.
Why? Boost.Filesystem v3 almost does all of this already. It would need
two changes to make it work exactly as you want:
- Interpret narrow strings as UTF-8 by default on Windows (the user
could always imbue it with the local code page facet if the really
wanted to interact with the 'A' versions of Windows APIs).
- Work around the MinGW 'bug' by incorporating some of your code.
> P.S.: The title of this mail is request for interest.
> It is ok not to have one.
I'm very much interested.
-- Easy SFTP for Windows Explorer (http://www.swish-sftp.org)