Beman Dawes:
A prototype implementation of version 3 of Boost.Filesystem is available for comment.
...
See http://svn.boost.org/svn/boost/sandbox/filesystem-v3/libs/filesystem/doc/v3_... for a fuller description of the prototype and links to the prototype implementation.
locale( "" ) is not correct on Mac OS X, where the API always takes UTF-8 char* and the filesystem uses wchar_t internally (AFAIK). One might make a case that a default UTF-8 locale is more "correct" on all OSes. On Solaris, it is the recommended choice by Sun for path encoding (AFAIK). All Linuxes are also moving to UTF-8 by default. There do exist vocal minorities that prefer other encodings though. :-) I'm, personally, using UTF-8 as the narrow encoding on Windows as well. The reason it works is that if one always gets a path object from the FS library it doesn't matter that the encoding doesn't match the ANSI APIs because they never get used. In addition, UTF-8 is roundtrip-safe, that is, path( p.string() ) produces a path that is equivalent to p; this is not necessarily the case with the system encoding, where some paths cannot be represented as a narrow string.