Re: [boost] [filesystem] Major changes before standardization

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-11-11 20:36:08

Beman Dawes wrote:
> At 12:41 PM 11/11/2004, Peter Dimov wrote:
>> In particular, the user cannot define the conversions
>> between the different path types, because they are implementation
> defined.
>
> The default conversion is implementation defined, but users can supply
> their own conversion. One use case I have in mind is a character
> based O/S which uses some MBCS encoding of paths that isn't UTF-8,
> but the user wishes to burn a CD with UTF-8 encoding. The user should be 
> able to
> provide such a conversion function, overriding the implementation
> defined default.

I see no need for custom conversions in this case. The user can just supply 
the appropriate narrow UTF-8 path directly. I also don't see where the 
implementation-defined default enters the picture, as the translation is 
between char and char.

> Another case of particular interest is Windows where the external
> type is 2 bytes and the user chooses path, which is char based, as
> the internal type for directory iteration. What happens when an
> directory entry uses the high-order byte? The default conversion
> supplied by the Windows API is lossy; the high order byte is simply 
> discarded.

The conversion depends on the current codepage, AFAIK. The high byte is only 
discarded if you're using windows-1251 (a superset of ISO-8859-1). A custom 
conversion simply cannot work portably.

Besides, if the user knows that he'll need a custom conversion, it's much, 
much easier to just use wpath.

Anything besides path/wpath is even less useful than basic_string that isn't 
string or wstring, amazing as this may be, and we all know how popular 
basic_string is.