Subject: Re: [boost] Silly Boost.Locale default narrow string encoding inWindows
From: Peter Dimov (pdimov_at_[hidden])
Date: 2011-10-27 14:01:52
Alf P. Steinbach wrote:
> On 27.10.2011 18:47, Peter Dimov wrote:
> > Alf P. Steinbach wrote:
> >
> >> However, I still ask:
> >>
> >> why FORCE INEFFICIENCY & AWKWARDNESS on Boost users -- why not just do
> >> it right, using the platforms' native encodings.
> >
> > Comment out the imbue line.
>
> But that line is much of the point, isn't it?
There wouldn't be much point in calling imbue if you didn't want a change in
the boost::filesystem default behavior, which is to convert using the ANSI
CP (or the OEM CP if AreFIleApisAnsi() returns false, if I'm not mistaken).
> > (The platform's native encoding is UTF-16. The "ANSI" code page, which
> > is not necessarily ANSI or ANSI-like at all, despite your assertion,
>
> The article you responded to did not contain the word "ANSI".
>
> Thus, when you refer to an assertion about "ANSI", you have fantasized
> something.
> I hope you are not going to go on like that.
>
>
> > [ANSI] is not "native"; the OS just converts from/to it as needed.
>
> OK, you need to learn a quite bit but
>
> (1) you appear to be very sure that you're already knowledgeable, and
>
> (2) you attribute things to me that you have just fantasized.
>
> That makes it very difficult to teach you.
>
> For narrow character strings in Windows, "native" and "ANSI" are
> interchangeable terms.
I will accept your definition for the time being and restate what I just
said without using "native":
Under Windows (NT+ and NTFS), the narrow character API is a wrapper over the
wide character API. The system converts from/to the ANSI code page as
needed. The narrowing conversion may lose data.
> > Your program
>
> No, again you're wrong: it's the Boost.Locale documentation's program.
>
>
> > will work fine until it's given a file name that is not representable in
> > the ANSI CP.)
>
> Nope, sorry, for any /reasonable interpretation/ of what you're writing.
File names on NTFS are not necessarily representable in the ANSI code page.
A program that uses narrow strings in the ANSI code page to represents paths
will not necessarily be able to open all files on the system.