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 accordingly? --rich