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
>> 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,
>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
>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
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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk