Re: [boost] Filesystem Library: Formal Review

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-09-19 05:58:06

Beman Dawes wrote:

>  >This still sounds strange to me. Your example for windows makes perfect
>  >sense, but the POSIX example is odd. Let's assume, in your example
>  >above, that p3 is also created from system specific path. Then
>  >
>  >   (p1 << p2).file_path()
>  >and
>  >   (p1 << p3).file_path()
>  >
>  >would be equal, althought p2 and p2 were created from radically
>  >different system specific paths. I think it should be either error, or
>  >those two file paths should not be the same.
> 
> Earlier path designs tried to trap more errors early, but that had a 
> serious downside: the only way to do so portably was for a path object 
> to keep track of whether it represents a directory or a file. This 
> because on some operating systems the rules for file path and directory 
> path validity are different. This made the library much harder to use 
> (more rules to remember), and made the code uglier (decorators saying in 
> effect "treat this as a file" or "treat this as a directory".

I'm not proposing such elaborate checks. I'm thinking about using << 
when second argument is absolute path, that is, path with has 
system-specific root in it.

> Remember that path objects are not ends unto themselves; they are just a 
> means to communicate paths to the operational functions that actually 
> perform I/O.  If the path is wrong in a way that makes it invalid, those 
> functions will report an error.  So it isn't really a question of 
> detecting errors or not, but rather at what point the errors are detected. >
> If anyone has ideas to tighten the specs on path so that more errors can 
> be detected, that's great as long as it doesn't make the interface 
> harder to use portably.

After some thoughts I believe that allowing system specific root in 
second argument of << leads to trouble. Consider windows case

   c:  <<   /foo  =  c:/foo
   c:  <<   foo   =  c:foo
   c:foo << /foo  =  c:foo/foo
   c:foo << c:foo =  c:foo/c:foo

The first case is ok. The second... I'm not sure. Results of the last 
two are just useless. In fact, you think if you stick to simple semantic 
of "<<" (which I think is good), then you should disallow 
system-specific roots in second argument, because most of the time it 
would require special handling. I think with 'absolute' root in paths 
will not be needed.

It means that if I do

   p1 << p2

p2 is always a relative path -- which is reasonable to me. You pull 
system specific component into some 'base' path and then add relative paths.

I think the check is better added, because currently system root in 
second arguments works only in one case, ("c:" << "/foo") on windows, 
and given wrong results in all others.

- Volodya