Beman Dawes wrote:
At 02:10 PM 10/25/2004, Peter Dimov wrote:
... I certainly wouldn't mind a filesystem _warning_ for nonportable paths, if we find a suitable delivery mechanism.
Interesting! A fresh perspective.
Let's see what can be done within the current design. A adaptor function could intercept what otherwise would be errors and turn them into warnings: bool warn_nonportable_name( std::string const & name )
{ if ( !fs::portable_name( name ) ) boost::issue_warning( "Warning, path contains non-portable name: " + p ); return true; }
Because the adaptor always returns true, an error exception is never thrown. This function could become the new default, or could be explicitly coded like any name_check function.
[...]
Does that capture what you had in mind?
Almost. The current validation scheme (with the above addition) is (IIUC): 1. Parse path according to grammar, throw on parse error; 2. Check every path element with checker(e), throw on false; Warning checker calls issue_warning on nonportable paths. What I had in mind was more like: 1. Parse path according to grammar, throw on parse error; 2. Call checker(e) for every path element; if false, call fs_nonportable_path_element Where: void (*fs_nonportable_path_element)( std::string const & path, std::string const & element ) = __fsnp_default; (as an aside, the exceptions really need their own types, because these aren't filesystem errors, i.e. no underlying filesystem error code is associated with them.) The general idea of this approach is that if the user wants an exception on nonportable path elements, the name checker can simply throw. If the user wants the current behavior, he can install an fs_nonportable_path_element that throws. Otherwise, he can install an appropriate handler that logs or ignores the nonportable path. It might even be possible to get rid of the default name checker "replaceable global constant", if the original default is now good enough and nobody needs to change it.