Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-09-18 11:17:44


At 11:37 AM 9/18/2002, Vladimir Prus wrote:

>> > fs::path p1("/home/ghost", fs::system_specific),
>> > p2("/a/b/c", fs::system_specific),
>> p3("a/b/c");

>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".

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.

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk