Boost logo

Boost :

From: Rich Johnson (rjohnson_at_[hidden])
Date: 2004-11-23 15:16:40

On Tuesday, November 23, 2004, at 10:27 AM, Angus Leeming wrote:

> Rich Johnson wrote:
>> On another topic....
>> I seem to recall a boost::filesystem 'is_equivalent_name()' or
>> 'name_equals()' convenience function mentioned sometime over the
>> last week or so. There's currently a fair bit of debate over
>> character
>> codings, etc.; this function would handle that.
> Thanks for the heads up. I skipped many of the 1200+ postings to the
> Boost Devel list since I read it last...
> I think that I understand what you're talking about. The fact that
> Win32 regards 'FileName' and 'filename' as equivalent file names
> unless the file has the FILE_FLAG_POSIX_SEMANTICS attribute set,
> right?
Hey, don't look at me for that info. I'm squarely in the linux & mac
camps--and happy there! :-)

My bias would be that if this sort of stuff is maintained below the FS
abstraction, then it's up to the FS to report whether there's a match
or not. Reverse-engineering the FS's logic should be avoided as much
as possible. [ Perhaps this would be better phrased as a requirement
of the boost::filesystem library. ]

>> AFAIK, these issues have (to date) been outside the scope of the
>> globber.
>> As they get settled out, this service should be utilized in the glob
>> predicate. My main concern would relate to performance--especially
>> regarding the frequency of constructing parsers.
> You mean the transformation of the globbing pattern '*/*.cpp' into
> the equivalent regex? That's done only once, right at the very start
> of the process. My tests indicate that my glob function has similar
> performance to the system glob on a 'nix box, so long as an
> appropriate container is used to store the results.

Yup. This is getting further into hypothetical design than is probably
appropriate, but....assuming the FS provides an is_name_equivalent()
convenience function (which I think it should):

A monolithic 'is_name_equivalent()' function that sets up and tears
down a regex each time it's invoked would have performance issues when
used in the context of the globber.

A reusable 'name_comparator' object(functor) supplied by the FS layer
could be instantiated once as part of the glob_predicate.

Of course this raises the issue of what happens when you glob across a
FS boundary(mount points and links)--must the name_comparator change


Boost list run by bdawes at, gregod at, cpdaniel at, john at