[boost] Re: boost::filesystem file restrictions

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-18 09:59:06

Beman Dawes <bdawes_at_[hidden]> 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