File operations: Win32 question [was Re: the first version of abstract path...]

From: mfdylan (dylan_at_[hidden])
Date: 2002-02-23 21:20:59

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 04:54 PM 2/23/2002, you wrote:
>  >----- Original Message -----
>  >From: "Beman Dawes" <bdawes_at_a...>
>  >To: <boost_at_y...>; <boost_at_y...>
>  >Sent: Saturday, February 23, 2002 1:31 PM
>  >Subject: Re: [boost] File operations: Win32 question [was Re: the
>  >first version of abstract path...]
>  >
>  >
>  >> If I understand you correctly, you are saying that this should 
also
>  >be
>  >> extended to include "const wstring& s" overloads?
>  >>
>  >> What should happen if the operating system doesn't support 
wstring
>  >file
>  >> names?
>  >
>  >This is not really a new problem.  A filesystem right now may only
>  >support a subset of the valid values of 'char' as characters in a
>  >filename.  If 'wchar_t' is used instead, the only thing that 
changes
>  >is that there are more unsupported characters.
> 
> Good point.
> 
However an OS may support a mapping from wcs to mbs (and vice 
versa).  For instance under plain-vanilla Win9x, you have to use 
WideCharToMultiByte(CP_ACP, ...); to convert a Unicode filename into 
a multibyte one that the OS can take and then convert *back* to 
Unicode for storage in a FAT extended name filesystem (this is what 
happens according to MS documentation).  It's also what happens under 
NT if you choose to use the ansi file api's (CreateFileA etc).
I would expect a Win32 implementation of fstream::open(const 
wchar_t*) to do this.  I'm not sure what I would expect a POSIX 
implementation to do (at worse I guess create a locale(""), grab the 
ctype facet and call narrow).  This has been discussed innumerable 
times on comp.lang.c++.moderated, but will little progress on a 
consensus.

Dylan