RE: [Boost-users] New design proposal for boost::filesystem

From: Ben Hutchings (ben.hutchings_at_[hidden])
Date: 2004-08-20 11:19:12

Carlo Wood <carlo_at_[hidden]> wrote:
> 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.