Re: [boost] Silly Boost.Locale default narrow string encoding in Windows

Subject: Re: [boost] Silly Boost.Locale default narrow string encoding in Windows
From: Alf P. Steinbach (alf.p.steinbach+usenet_at_[hidden])
Date: 2011-10-27 13:17:45

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?

> (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.

They mean the same, namely the codepage identified by the GetACP() function.

This is not a particular codepage, it is configurable.

On my machine, and most probably on yours, it is codepage 1252, Windows 
ANSI Western.

"Native" means the encoding used and expected by the OS' API functions.

For narrow character strings in Windows, that's Windows ANSI.

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

I can imagine that maybe you're thinking about setting ANSI CP to 65001, 
which however is not reasonable.

Cheers & hth.,

- Alf