[boost] Re: Re: Any interest in a boost::glob() function?

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

--rich