Carlo Wood
I propose the following design. The aim of boost::filesystem should be to support the following coding idiom:
* The programmer should take care to only handle two types of paths in his application:
1) Complete paths 2) Relative paths
Are there any other types?
* The programmer will have to specifically tell the libary when a constructed path is 'native' and when not. <snip>
Sounds reasonable.
I propose two design changes:
1) 'native' is now not only a representation, but an *internal state* of fs::path. (this has no effect on the representation as returned by fs::path::string()). 2) All 'complete' paths are automatically marked as 'native'.
Examples, the following code is legal:
fs::path p1("C:\foo\a.exe", native); // Fails on linux, // success on windows.
You have that backwards. "\f" and "\a" are not valid in a filename in Win32. Now if those backslashes are changed to "\\" this will work on Win32. Either version of the name will work on Linux because all characters except "\0" are valid in a Unix filename.
fs::path p2("/usr/src/a.out, native); // Fails on windows, // success on linux.
That should work on Windows too because "/" is supported as an alternative to "\\". <snip>
But in case more than one 'working' directory seems needed then we can add support for that too by allowing to construct paths with a reference to the (complete/native) working directory. Ie,
fs::path home_base(...); // ...
fs::path runtime_rcfile(home_base); // ...
runtime_rcfile = "myapplication/config/runtime/rc";
which is then relative to `home_base' instead of a single, global 'working directory' (as now returned by fs::current_path()). <snip>
That doesn't seem right to me. Assignment should overwrite the old value rather than combining with it.