From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-11-15 11:43:59
Beman Dawes wrote:
> At 07:13 AM 11/15/2004, Peter Dimov wrote:
>> Now the behavior of the calls is as follows:
>> CreateFileA( "C:/foo.txt" ); // char -> wchar_t OS conversion
>> CreateFileW( L"C:/foo.txt" ); // no OS conversion
>> CreateFileA( "D:/foo.txt" ); // no OS conversion
>> CreateFileW( L"D:/foo.txt" ); // wchar_t -> char OS conversion
> Yes, that's my understanding too.
Now this is what happens when you declare wchar_t to be "native".
fs::function( "C:/foo.txt" ) converts to wchar_t, circumventing the OS
conversion (you just argued that this was unacceptable).
fs::function( L"C:/foo.txt" ); works as before.
fs::function( "D:/foo.txt" ) converts to wchar_t, then the OS converts back
(to "D:/foo.txt" if we are lucky).
fs::function( L"D:/foo.txt" ) works as before.
>> Furthermore, consider a typical scenario where the application has
>> its own "native" character type, app_char_t. In a design that enforces a
>> single "native" character type boost_fs_char_t ("native" is a
>> deceptive term due to the above scenario), there are potentially
>> redundant (and not necessarily preserving) conversions from
>> app_char_t to boost_fs_char_t and then from boost_fs_char_t to the
>> filesystem character type.
> Yes. Note that even if a dual scheme is used, that same situation
> might arise:
> if ( fs::exists( "c:foo" ) ) ...
> if ( fs::exists( L"d:foo" ) ) ...
> Notice that a narrow character path was given for the wide-character
> filesystem and a wide character path given for the narrow-character
> file system. If the type of the user supplied path is what determines
> the API to use, the O/S may still have to do conversions when there
> is a mismatch with the file system.
Of course. The point I am making is that, on a dual OS, (a) the only place
where conversions happen must be the OS and (b) at most one conversion
> Do you see any alternative?
There need not be an alternative. The idea is to not do worse than that.
> Your strongest argument IMO is the point about conversions not
> necessarily being value preserving.
This is only an example of how things can go wrong. Another would be when a
service pack or a new version changes the default OS conversion. If you rely
on the ability to duplicate the OS behavior exactly, there'll be trouble.
The bottom line is that, on a dual OS, if we get a narrow string from the
user, we should ultimately pass a narrow string to the OS, and if we get a
wide string, we should pass a wide string. Everything else will be wrong in
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk