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.
> >> > 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
> 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
> >> 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
Expression templates are nice.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk