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
>> 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,
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
>> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk