Excellent, thanks, that helped. Is that an acceptable method to do this? (using boost::filesystem::native) Or are there other preferred methods of setting up path objects? Graham On 4/17/07, Rush Manbert wrote:

Graham Reitz wrote:

...

Why does the following path initialization throw this?

"boost::filesystem::path: invalid name "c:" in path: "c:/dev/Sandbox/file_system/ textfile1.txt"

How do you set paths that should work on windows and linux without avoiding this issue? Since linux doesn't have drive like C: D: and etc?

try { // Is this not an appropriate method to initialize path objects? path text_file(current_path().string() + "/textfile1.txt");

if (exists(text_file)) { cout << file_size(text_file) << endl; } } catch (const filesystem_error& e) { cout << e.what() << endl; }

I am running this under windows.

I think you need to use the native name checker like this:

path text_file(current_path().string() + "/textfile1.txt", boost::filesystem::native);

- Rush _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

On 4/17/07, Graham Reitz wrote:

Excellent, thanks, that helped. Is that an acceptable method to do this? (using boost::filesystem::native)

In the beginning, name checkers were created. This made a lot of people very confused, and has been widely regarded as a bad idea. They're not in the TR2 proposal, nor the version of the library that's in 1.34, so turning them off is not a problem.

Or are there other preferred methods of setting up path objects?

complete (or system_complete) might be convenient for you. ~ Scott McMurray

On 4/18/07, Rush Manbert wrote:

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