Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at