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.