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)
http://art-blog.no-ip.info/files/nowide.zip
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 API?
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. Alex -- Easy SFTP for Windows Explorer (http://www.swish-sftp.org)