Re: [boost] Re: boost::filesystem file restrictions

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
> "native".
> 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.