RE: [boost] Re: Re: New design proposal for boost::filesystem

From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-08-26 11:51:06

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