Beman Dawes <[EMAIL PROTECTED]> writes: > Yes. Plus there are some other issues. > > The actual interface would include boost::filesystem::path > constructors which take an additional argument to explicitly specify a > name checker function. In working out use cases, it seems that > temporary overrides of the default function are best handled via these > constructors. That leaves only the case of wishing to permanently > replace the default function, and the simpler approach you are talking > about would be better for that. > > For safety, such a set_legal_name_policy() would use the > write-once-before-read idiom to avoid a dangerous global > variable. (I'm actually thinking of "name_check" for the type, and > "set_name_check" for the function name.) > > I'm about to post a message asking for opinions on the details of the > policy function pointer or object.
This starts to align with what I've been thinking. Every path object could maintain a chain of checkers, and combinations of path objects (e.g. via operator/) would use the union of the checkers of their components, so that checking would never become less-restrictive silently. 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. -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
