>"Peter Dimov" <[EMAIL PROTECTED]> writes: > >> I am not sure that it should be the responsibility of the path class to >> enforce some notion of portability. Wouldn't it be more appropriate to >> defer the portability check, if any, to the point where the path is >> actually used in a filesystem operation? > >I agree. Having portability enforcement can be useful, but AFAICT the >way it's currently supplied is biased for the 1% case. There's an >enormous class of applications which gets paths from the user or one >part of the platform implementation (e.g. a file selection dialog), >possibly does some manipulation on the path, and uses it to open some >local files on the platform.
Yes, of course. There is no check performed in those cases. The only names checked are on those portions of a path created via the generic grammar constructors. The check does not apply to the native constructors.
> The only category of application which >needs enforced path portability, AFAICT, is the one which stores paths >in some file meant to be used on other platforms, or arguably those >which encode paths directly in portable code. These applications are >comparitively rare IME.
Only those cases are checked, so if they are rare in your code, then you won't experience a problem. Let me know if you run into any cases where name checking gets applied to a native path; that shouldn't be happening.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
