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

From: Angus Leeming (angus.leeming_at_[hidden])
Date: 2004-11-23 07:48:35

Rich Johnson wrote:

> 
> On Tuesday, October 5, 2004, at 04:18 AM, Angus Leeming wrote:
>>
>> Actually, the glob_iterator I've implemented and have just posted
>> here:
>>
>> http://www.devel.lyx.org/~leeming/glob.zip
>> (Docs can be viewed on line at:
>> http://www.devel.lyx.org/~leeming/libs/glob/doc/html/)
>>
>>
> Hi folks--
> 
> I'm sorry I've been offline for a while and missed this thread.
> 
> Angus, GREAT job completing the grammar and packaging everything up!
> Your modifications look like a _major_ improvement over my QnD
> implementation--especially incorporating spirit.  I can't wait to
> try them out.
> 
> My only quibble is with the Windows #ifdef's and specialization
> flags--I much prefer subclassing.  Before everyone jumps on that, I
> know it's primarily a matter of style--and that performance often
> rules the day.
> 
> I especially abhor #ifdef's in the body of the code--when
> unavoidable they should be restricted to a configuration
> section--such as initializing a class variable.
> 
> There's something funny with your performance stats:   the
> glob_function results show an elapsed time that's less than the sum
> of system and user time.  How can that be?

Hi, Rich. Apologies for the delay in replying. I've been out of town.

Stats on dual processor machines are too weird to query too hard. I 
wouldn't worry.

I have been away for a couple of weeks but was busy playing around 
with 'glob' before I left. It transpires that a boost::glob function 
that stores its data in a std::vector has similar performance 
characteristics to the system glob function. The interface is

template <typename ContainerT>
void glob(ContainerT & container, 
          std::string const & pattern,
          filesystem::path const & working_dir,
          glob_flags flags);

The only requirements on ContainerT is that it should have a 
push_back member function.

Using a std::list rather than a std::vector degrades performance 
through all those calls to operator new.

Using Gennadiy's glob_iterator suggestion as the interface has 
performance an order of magnitude worse than that of the glob 
function with a std::vector<filesystem> as the container.

Regards,
Angus