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":
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
> > 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk