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()
> > (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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk