At 08:36 PM 11/11/2004, Peter Dimov wrote:
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 considered that. For most users, who will rarely if ever need a custom conversion, it would be fine to require them to do any custom conversion themselves before constructing a path. But a few users will need to do custom conversions for virtually every use of the library (probably because their O/S just traffics in raw chars, yet they need a wide character encoding.) These users would be helped a great deal by custom conversions. Maybe that is an extreme corner case - it certainly would simplify the design to eliminate custom conversions. See my reply to Vladimir Prus regarding a single path class for an example. One case where a custom conversion is required is for a user defined string type. There isn't any default; the user has to supply the conversion. I know you don't believe in the usefulness of such user defined string types, but I'd be surprised if the committee would accept elimination of user defined string types.
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.
The issue isn't the popularity of basic_string. As long as there are even a few users who depend on basic_strings other than string and wstring, the committee will probably want to support it. Also, remember that basic_string<char16_t> and basic_string<char32_t> may well be mandated in the fairly close future. --Beman