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