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.