From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-08-21 10:47:57
Beman Dawes wrote:
> At 05:46 PM 8/18/2003, Peter Dimov wrote:
> > I agree except that IMO the 90+% case is "I'm doing generic path
> > manipulation" which is portable path format ("x/y", not "x\y" or "x:y")
> > but no constraints on charset except of course '/' and '\0'.
> Yes, that's the point I made in a reply to Dave; it is quite
> desirable to specify the default syntax as generic but it is possible
> and perhaps even desirable to specify the default name checker as
> something else.
We seem to be reaching an agreement.
> That "something else" could be "none", as you suggest above, or
> The advantage of "native" is earlier detection.
And the disadvantage of "native" is that it introduces implementation
defined behavior into an otherwise well specified operation. Now you don't
know what p / "$" will do. It depends on the platform.
One might argue that this is actually desirable, that p / "$" is an
inherently nonportable construct. Perhaps. I just like things to perform as
specified, without implementation defined behavior thrown in. Generic path
manipulation can be useful even if you don't ever go to the filesystem.
> Presumably if a program uses some character in a name that isn't
> allowed on the native platform, the error will be detected when the
> path is actually used in some operation. That may come a long time
> (due to heavy computation or I/O, or because the use only occurs
> rarely) after the path was created. I've had error reports when this
> happened with some commercial software I wrote. The operator entered
> an invalid name for an error file, and it was a long time before the
> file was used, forcing a long job to be rerun. Thus early error
> detection can be a plus.
True, but won't operator input be in native format? path(input, native) will
perform the necessary checks.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk