|
Boost : |
From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-04-20 08:51:20
At 08:22 AM 4/9/2003, Christian Engström wrote:
>In my application I need to handle paths that contain wildcards, such as
>for example "foo/chapter?.txt" or "bar/*/index.html".
>
>I believe that the boost::filesystem::path class would be ideal for this
>purpose, since it hides all the messy platform dependent stuff, and
>provides a convenient interface (I am particularly impressed by the bold
>use of the / operator) for manipulating the individual parts of the
>path, which is something that I need to be able to do in order to
>isolate the wildcard items and handle them in an appropriate manner.
>As the class stands at the moment, however, I cannot do this, since the
>generic format bans the use of the wildcard characters "*" and "?".
>
>Does it really have to?
>
>The rationale stated in the documentation is that they are disallowed
>because you couldn't reasonably expect them to work as part of an actual
>file name, at least not in a portable manner. While this is of course
>true, it doesn't necessarily mean that the path class is responsible for
>throwing them out, since the path class is explicitly documented as
>providing no guarantee that the path is in fact valid on any particular
>system.
>
>If I actually were to try to create a file with a name that contained
>either of these characters, or, for that matter, a file name that was
>illegal in some other way, it would be up to the fstream open function
>to react to the problem, so it would not go undetected anyway.
>
>Is this something that could be changed? I believe that it would be
>technically trivial to do it (just remove the two characters from line
>108 in path_posix_windows.cpp), so it is really more a question of
>opinion than anything else.
I think that your need is both valid and commonplace, but that the way to
handle it isn't necessarily to modify the filesystem library.
Rather, think about using a filter iterator. See
www.boost.org/libs/utility/filter_iterator.htm
There are a couple of caveats: (1) I haven't actually tried it, so don't
know if it is a practical solution, and (2) Dave, Jeremy, and Thomas are
working on a major update to iterator adaptors so details may change once
they are done.
If you try this approach, please post something letting us know if the
approach worked for you.
Thanks,
--Beman
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk