Boost logo

Boost :

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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at