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
>> 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 &
(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. :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk