[boost] Re: boost::filesystem file restrictions

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-21 12:53:20

Beman Dawes <bdawes_at_[hidden]> writes:

> At 05:28 PM 8/18/2003, David Abrahams wrote:
>
>  >Sure.  The question is:
>  >
>  >       path x('foo/bar', portable_check);
>  >       path y('baz', native_check);
>  >
>  >       path z = x/y; // Which checks are made?
>
> None. x and y were checked when constructed. 

Then nothing prevents the combination of names that were checked for
windows and posix respectively, resulting in something that works
nowhere?

How will we check the result?

> Remember that we are talking about checks on individual names, not
> the entire path.

You say that like it's an established principle, but I'm not aware of
it.  Why is that the right thing to do?

> Now here is another case:
>
>          path u = q / "abc";
>
> q will not be (re)checked. "abc" will be checked by the default checker.

Which is...

>  >>  >  Of course, though I think this goes against the grain of
>  >>  >the library, I believe the default checker should always be the for
>  >>  >the native platform.
>
> See next response below.
>
>  >>
>  >> Because the native platform may support several different file systems
>  >> within the same directory tree, it isn't possible to perform a full
>  >> and correct lexical (inspection of the name only) check for the native
>  >> platform. You in effect have to try the path and see if the operating
>  >> system accepts it. What the lexical level name check done by class
>  >> path is trying to do is early detection of gross naming errors.
>  >
>  >Sure; I just don't want to have to be explicit about anything just to
>  >say "I'm doing native path manipulation", since I believe that's the
>  >90% case.  I don't want to be stopped by irrelevant portable path
>  >considerations nor uglify my code to avoid it.
>
> At worst, you would have to code a single function call at the
> beginning of the program to change the default:
>
>    int main()
>    {
>      boost::filesystem::set_default_checker( native );
>      ...
>
> Note that set_default_checker() uses the write-once-before-read ideom,
> so is safe from "global variable" abuses.

I'm not familiar with this idiom, but as far as I can tell it provides
only a kind of runtime safety, and it means that libraries can never
use the default, which in practical terms means that nobody trying to
build reusable for a specific program with reusability in mind can use
the default.

> Back to the main questions. There are really two separable issues:
>
> * What is the best default syntax? Generic or native?
>
>    I'm convinced the best answer is generic, and my certainty
>    seems to be increasing with time as I see more use cases.

I think if you go with Peter's idea, it's "generic but not
neccessarily portable", and that's fine with me.

> * What is the best default name checker?
>
> Now that there is an easy and safe way (write-once-before-read)
> for a program to change the default name checker, the decision
> as to the default is less critical. 

I'm less optimistic than you about the consequences of having a
global name checker.

> It comes down to the most common use cases. I've got six right now,
> and will read the rest of this thread to see if any others are
> mentioned.
>
>  >...
>  >> But because it can't be an iron-clad guarantee, I'd prefer not to
>  >> build an even mildly complex mechanism to support it. Particularly
>  >> since some programmers will disable it anyhow.
>  >
>  >You need to define sensible semantics for path combinators then.
>
> I think the current semantics are fine. See the examples above.
>
> What does need to be considered is ways to combine name checkers
> without the user having to write a little function. It would be
> helpful to be able to easily say "use the windows checker && the posix
> checker".

Expression templates are nice.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com