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