From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-21 09:45:46
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. Remember that we are talking
about checks on individual names, not the entire path.
> path q = z/y; // which checks are made?
Again, none, since z and y have already been checked.
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:
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.
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.
* 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. 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".
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk