Re: [boost] Silly Boost.Locale default narrow string encodinginWindows

Subject: Re: [boost] Silly Boost.Locale default narrow string encodinginWindows
From: Peter Dimov (pdimov_at_[hidden])
Date: 2011-10-27 15:07:25

Alf P. Steinbach wrote:
> On 27.10.2011 20:01, Peter Dimov wrote:
...
> > 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.
>
> Right, that's one reason why modern Windows programs should best be 
> wchar_t based.

This is one of the two options. The other is using UTF-8 for representing 
paths as narrow strings. The first option is more natural for Windows-only 
code, and the second is better, in practice, for portable code because it 
avoids the need to duplicate all path-related functions for char/wchar_t. 
The motivation for using UTF-8 is practical, not political or religious.

> The example that I gave at top of the thread was passing a `main` argument 
> further on, when using Boost.Locale. It causes trouble because in Windows 
> `main` arguments are by convention encoded as ANSI, while Boost.Locale has 
> UTF-8 as default. Treating ANSI as UTF-8 generally yields gobbledygook, 
> except for the pure ASCII common subset.

Yes. If you (generic second person, not you specifically) want to take your 
paths from the narrow API, an UTF-8 default is not practical. But then 
again, you shouldn't take your paths from the narrow API, because it can't 
represent the names of all the files the user may have.