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

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
 >> 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