Re: [boost] Filesystem Library: Formal Review

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