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

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)
> 
>    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)