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.