Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-18 08:26:33


At 05:43 AM 8/18/2003, John Torjo wrote:
>> The current approach is clearly too restrictive and isn't satisfactory.
>> Beyond the problems you mention, there really isn't a single standard
for
>> portability. Even 8.3 names aren't portable to systems which don't
allow
>> periods in names. A whole family of checkers is needed, giving various
>> degrees of portability. Some should be supplied with the library, but
>users
>> also need to be able to provide their own.
>> [...]
>
>> <boost/filesystem/path.hpp> added this:
>>
>> typedef bool (*is_portable_test)( string & candidate );
>>
>> class scoped_portability_policy : noncopyable
>> {
>> public:
>> explicit scoped_portabiity_policy( is_portable_test f );
>> ~scoped_portabiity_policy();
>> };
>>
>
>I'm not sure 'portability' is the right word here.
>
>Since it can be overridden by the user, maybe a better name would be:
>is_legal_name_test - and the user can override it to suit its needs.
>
>I don't quite like is_portable_test, since I assume there is only
>one 'portability', not more (at least, this is what I think, when
>discussing portability). For instance, when talking about a portable
name,
>I assume there is a clear definition of what that means to everybody
>(and I don't assume users could/should override that ;).
>
>
>That said, instead of a scoped portability policy, which will go rather
>bad with thread-safety, maybe, just a simple
>set_legal_name_policy( is_legal_name_test f); would look better.
>
>Users would (should) set this in main(), while there are no more threads,
>and it could play nicely with thread-safety as well.

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.

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk