Re: arguments parsing, wildcard matcher

From: dylan_at_[hidden]
Date: 2001-11-19 19:14:05

--- In boost_at_y..., "Henrik Ravn" <henrik_at_r...> wrote:
> > > struct file_finder
> > > {
> > > 	file_finder(const char* pattern);
> > > 	~file_finder();
> > > 	typedef const char* const* iterator;
> > > 	operator bool() const;
> > > 	iterator begin();
> > > 	iterator end();
> > > private:
> > > 	glob_t glob_;
> > > };
> > > 
> > 
> > It doesn't allow access to file info (size, date/time etc) 
because 
> > glob doesn't do this, and you get this easily enough once you 
have a 
> > filename.  I think something like this needs to be integrated 
with 
> > the directory iterator stuff already in boost.
> > 
> > Btw the reason for operator bool is to allow:
> > 
> > if (file_finder finder("*.dat"))
> > {
> >      file_finder::iterator i = finder.begin(); 
> >      do
> >          process_file(*i);
> >      while (++i != finder.end();
> > }
> > else
> >     throw no_files_found; 
> 
> This could be done without operator bool, by including bool empty()
> const and then go:
> 
> file_finder finder("*.dat");
> if (finder.empty())
> 	throw no_files_found;
> for (file_finder::iterator i = finder.begin(); i != finder.end() 
++i)
> 	process_file(*i);
> 
> which I think I like better.
> 
> Henrik
> 
It's probably more consistent with std c++ containers.  Actually 
making it as fully compatible with a std c++ container as possible is 
probably worth doing, which for POSIX (glob) is pretty 
straightforward (that is, length(), const_iterator etc are easy to 
do), for the Windows version is not quite so straightforward, as it 
would basically mean doing the actual FindNext... loop in the 
constructor as opposed to dynamically while iterating.  In fact it 
would probably be just as easy to implement glob itself using 
FindFirstFile etc then the C++ class wrapper needn't be any different.
It is worth adding a function to re-use the same "finder" object to 
try a different pattern match?

Dylan