[boost] Re: status of wchar_t support in filesystem::path?

From: Paul Miller (paul_at_[hidden])
Date: 2004-02-16 09:08:37

>  >On Windows and OS X, you can work with paths in Unicode.
> 
> Do you have a reference for a good source of information about OS X 
> handling of paths?

Here is a good tech-note on the "new way" vs. the "old way":

<http://developer.apple.com/technotes/tn2002/tn2078.html>

You can get to a Unicode path (encoded as UTF-8) from an FSRef through 
FSRefMakePath, or through CFURLs which seesm to be the preferred way of 
working with any kind of locator (file-based or not) on OS X.

>  >Is there progres toward a wchar_t-aware path?
> 
> Yes. I now have the outline of a design for the internationalization of 
> Boost.Filesystem paths. The C++ committee meets in Sydney, Australia, 
> next month, and the LWG will be queried to see if they are interested in 
> the standardization of an internationalized version of Boost.Filesystem 
> based on that design. If so, I'll start work on a prototype.

I'd love to see it, and help in any way I can.

IMO, filesystem::path is somewhat useless for I18N-aware applications.

Linux might be the center of the universe to some, but I18N is extremely 
important on Windows and Mac, and they have both adopted Unicode.

But, I think it could be made usable simply by supporting wchar_t 
strings. I am happy with having the onus of dealing with the long paths 
themselves in file operations or UI on my end - I don't need to wait for 
long path support in the C++ library, since I can implement the custom 
open myself.

>  > I notice the existing posix checks
>  >would fail horribly in this case. Is a UTF-8 checker in order?
> 
> It wouldn't hurt. Care to contribute one?

I could probably be talked into it. On the other hand, it path supported 
wchar_t strings, it would be much more straightforward to deal directly 
with wchar_ts.