Re: [boost] Re: Re: Oughtn't filesystem::path acc ept the "*" and "?" wildcards?

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-04-21 10:03:03

At 10:37 PM 4/20/2003, Edward Diener wrote:

 >Beman Dawes wrote:
 >> The idea is that rather than directory iteration returning iterators
 >> for
 >> all path entries, it would only return those which passed a predicate
 >> which was driven by the pattern. For some uses, the pattern might
 >> more flexibly
 >> be a regular expression rather than the traditional (but non-portable)
 >> wildcard patterns provided by various operating systems.
 >
 >Yes, that would work but would consume extra time when done from the
 >end-users point of view rather than the implementors. First one has the
 >usual directory iterator returning all files, then one filters it for the
 >files one wants. At the native API level, admittedly non-portable,
 >functions
 >already exist to filter the entries based on wildcard patterns as the OS
 >searches the disk directory.
 >
 >Finally trying to filter an already existing file list can be far more
 >difficult than letting the OS use its built-in heuristics and 
understanding
 >of wildcards to automatically do it for you. Don't get me wrong, iterator
 >adaptors are great and the filter adaptor is a great example of using it,
 >but in this case it is probably not what an end-user wants.

There are two use cases for filesystem functionality. One is the portable 
case, where paths are often explicitly specified in program code, and the 
need is portable and as-identical-as-possible operation across operating 
systems. The second is the "native" case, where paths often originate as 
user input, and the need is for portable code that still can handle native 
format paths.

What is very explicitly not a supported use case is for providing simply a 
new but still non-portable interface to non-portable operating system 
API's. If that is the need, just call the non-portable operating system 
API's directly.

As far as filtering goes, my primary interest is the portable case. 
Presumably this involves a generic portable filter grammar, and that 
requirement seems made to order for regular expressions. But it is hard to 
tell if that idea is actually useful without more study and 
experimentation.

Once the portable case is handled, then I'm willing to see if native format 
paths with wild-cards can be accommodated. But solving the portable case 
seems to me to be most important.

My highest current priority for filesystem is work on internationalization, 
specifically portable wide-character paths. Until that problem is solved, 
the filesystem library can't be proposed for standardization.

--Beman