From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-11-12 10:50:01
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
>> 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
>> 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
>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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk