Re: [boost] boost::filesystem file restrictions

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-14 20:16:05

At 01:40 PM 8/14/2003, Peter Dimov wrote:
 >Beman Dawes wrote:
 >>
 >> The current approach is clearly too restrictive and isn't
 >> satisfactory. Beyond the problems you mention, there really isn't a
 >> single standard for portability. Even 8.3 names aren't portable to
 >> systems which don't allow periods in names. A whole family of
 >> checkers is needed, giving various degrees of portability. Some
 >> should be supplied with the library, but users also need to be able
 >> to provide their own.
 >>
 >> OTOH, a function that has to be explicitly called isn't going to be
 >> effective. Manual checking is too laborious in code that does a lot
 >> of path manipulation. A one time I took several pages of code and
 >> tried to add explicit checks. The code turned into a mess. Manual
 >> checking is also
 >> likely to be ignored by the very programmers who need it the most;
 >> those
 >> who have firm but erroneous ideas about what is or isn't portable.
 >
 >I am not sure that it should be the responsibility of the path class to
 >enforce some notion of portability. Wouldn't it be more appropriate to
 >defer the portability check, if any, to the point where the path is
 >actually used in a filesystem operation?

That's too late. A real path is often made up of some native elements 
(which the portability check doesn't apply to) and some portable elements 
(which the portability check should be applied to).

The earlier the error can be detected, the better. Also, a path is only 
constructed once, but may be use multiple times.

Because it is an invariant that any fully constructed path has already been 
error checked (and operations like appends in effect construct their 
argument first if necessary to guarantee the invariant), lots of other code 
doesn't have to worry about error detection.

I'm very comfortable with applying the error check a construction time (or 
equivalent for rhs arguments), and not applying it at all for native paths. 
What I'm having trouble which is the mechanism for selecting the particular 
error function to apply.

That would be easy if we accepted the native platform as the default, and 
portable cases had to be specially coded. But my interest is in portable 
semantics as the default.

--Beman

--Beman

--Beman