On 4/18/07, Rush Manbert
This is the sort of "smarter than me" answer I was hoping to see. :-)
Glad. http://www.boost-consulting.org/boost/libs/filesystem/doc/faq.htm : * Why isn't automatic name portability error detection provided? A number (at least six) of designs for name validity error detection were evaluated, including at least four complete implementations. While the details for rejection differed, all of the more powerful name validity checking designs distorted other otherwise simple aspects of the library. Even the simple name checking provided in prior library versions was a constant source of user complaints. While name checking can be helpful, it isn't important enough to justify added a lot of additional complexity.
But I have a question. If I get a path string from the native (Windows or Mac, for instance) API, and there is no native name checker, how do I generically construct a path from it? Is the platform-specific format dealt with behind the scenes in 1.34?
http://www.boost-consulting.org/boost/libs/filesystem/doc/index.htm#tutorial : The string passed to the path constructor may be in a portable generic path format or an implementation-defined native operating system format. Access functions make my_path contents available to the underlying operating system API in an operating system dependent format, such as "some_dir:file.txt", "[some_dir]file.txt", "some_dir/file.txt", or whatever is appropriate for the operating system. If class wpath is used instead of class path, translation between wide and narrow character paths is performed automatically if necessary for the operating system. For further details, see http://www.boost-consulting.org/boost/libs/filesystem/doc/tr2_proposal.html#... ~ Scott McMurray