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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-11-11 21:03:49

Peter Dimov wrote:
> Beman Dawes wrote:
>> 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.

I guess you have something like this in mind:

    void burn( wpath const & source, wpath const & dest );

where 'source' needs to be converted to a narrow path using encoding #1, but 
'dest' needs to be converted to a narrow path using encoding #2 (UTF-8), 
_but_ the system doesn't know that so the user needs to override the 
conversion of 'dest'.

Still makes no sense to me. :-)

    void burn( path const & source, path const & dest );

can be used to accomplish this, but it's a hypothetical scenario. If the 
system doesn't know that the CD needs its path UTF-8 encoded, nobody will be 
able to read that CD back!

But I may be missing something. Perhaps if you illustrate the user 
path/conversion examples with code...

>From where I sit, the library provides:

    void fs_function( path const & p );
    void fs_function( wpath const & p );

One of these is native, the other is either native or converts and calls the 
other. I can't "imbue" a custom conversion in path or wpath, but I don't 
have to, because I can just convert the path myself beforehand (with the 
exact same loss of portability).

Turning the filesystem API into

template<class Ch, class Tr> void fs_function( basic_path<Ch, Tr> const & 
p );

(thereby moving the entire implementation in headers) doesn't seem to buy us 
much; the native API is not, and will never be, templatized. :-) Not to 
mention that third-party libraries will be reluctant to adopt this style, as 
this requires them to ship source.

In fact, many libraries will probably even omit the wpath overloads. If we 
could somehow combine path and wpath into one class, this would neatly 
sidestep this missing wpath overload problem. :-)