At 09:33 AM 8/25/2004, Bennett, Patrick wrote:
> If I can't write a
>portable (to at least Linux and Windows), internationalizable
>application with boost::filesystem then it's of no use to (at least) me.
And a lot of other people. I'd like to see the library become part of
std::tr2, and lack of internationalization is the main impediment to that.
I've spent a lot of time for the last two years looking into the issues,
and am pretty close to being ready to make a detailed proposal.
>This is why I suggested that UTF-8 be used as boost::filesystem's
>encoding. It can be passed through as-is or converted as needed on each
>platform and it would be backwards compatible with existing
>boost::filesystem code.
For standardization (and I don't have any interest in internationalization
except in the context of standardization) I don't think any proposal will
fly unless it is in sync with current standard library
internationalization.
That means that the internal encodings must be char, wchar_t, or a template
parameter charT. Once the Unicode TR being worked on is accepted, then
those character types will be presumably be added. Just as with strings,
presumably there will be path and wpath typedefs, and then Unicode typedefs
when they evolve.
As far as external encodings go, there will be a program default (which
defaults to the platform default, but can be set to a user specified
encoding), but individual paths can be constructed using a user-supplied
external encoding if desired. Translation issues between encodings are
messy, to say the least.
Note that there has to be a way to pass strings in the operating system's
external encoding on to (at the lowest level) file open functions, and that
the current standard does not provide this. Bill Plauger has proposed the
addition of this functionality to the standard, so that aspect is moving
forward.
--Beman
