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
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk