Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-07-19 20:53:54

At 01:15 PM 7/19/2002, Giovanni Bajo wrote:

>after having played a bit with the file system library, I have several
>feedbacks to share.
>What's the canonical form for "c:\windows"? The only way I found to setup
>path like this is fs::path("c:\\windows", fs::path::system_specific).

That's correct, and that is a deliberate design decision arrived at after
months of considering other schemes.

The basic problem is that the specification of root directories is
inherently non-portable. Even something as simple as "/" has
somewhat different meanings between POSIX, where it is an absolute path to
the filesystem root, and Windows, where it is a relative path to the
current drive's root.

The fs::path::system_specific constructor allows for the construction of
paths with roots which are drives, devices, volumes, or any other kind of
system-specific root. Typical sources of such base paths are user input or
the initial_directory() function. The program itself is usually better off
(and much more portable) to deal only in paths relative to that base

>understand there are platforms where drives are mapped to directories.
>it sounds strange that there is simply no way to specify a drive when
>the library under Windows. Actually, if you print a path constructed as
>above, it displays "c:/windows", but you can't construct the path with
>syntax. So, my point basically is that I want a way to select a driver
>Windows in canonical form. Suggestions are to accept either "c:/windows"
>"/c/windows" (changing the library so that the first directory in an
>absolute path is always the drive name - under Windows).

The idea is that paths constructed with the regular (no 2nd argument)
constructor are portable (except for the name issue; there are separate
functions to help in dealing with that).

Paths constructed with the additional constructor argument
"system_specific", aren't limited. The syntax is deliberately a bit
longer; we only want people to use this form if they have really thought it
out and need it.

I'm quite happy with the approach. It encourages portability without
requiring it.

>I pretty much don't like "directory_iterator" in its current form. When I
>read the word iterator, I expect to have a container associated to it
>its begin() and end() members. directory_iterator behaves as a STL
>for some things (full InputIterator semantic), but does not for others
>incapsulate its own 'container' to the user).

The approach is hardly unheard of. See the standard's stream iterators
(section 24.5 of the standard).

By the way, Dietmar Kühl did the original design and implemention of

>My proposal is creating a new class called 'directory_list' which would
>as a container (I think it should match what it's now called
>directory_iterator_impl), and then defining directory_list::iterator used

>to simply navigate through it as normal.
>Basically, 'directory_list' would be very very similar to a
>(it might be its underlying implementation), with the list holding the
>of the files within the directory (and with lazy evaluation to be sure it
>gets filled only when the informations are requested by the user). It
>have a constructor getting a fs::path (throwing an exception if the path
>does not represent an existing directory). It would also implement most
>(all?) the member functions found in a list<fs::path> (like begin(),
>size(), erase(), etc). Giving it a full container semantic...

A directory isn't a container, anymore than an I/O stream is a container.
They are operating system resources, and the only thing that a library can
do with them is whatever is provided the OS API.

That's why access via an input iterator makes sense. It is a thin wrapper
that papers over differences between operating systems, yet in a form
familiar to C++ programmers.


>Filtering and recursing subdirectories are very important because, in my
>opinion, they are the two most common operations done while browsing a

Sure, and trivial for the user to code given the basic toolkit provided by
the Filesystem Library components, and all the tools available for working
with iterators.

In the lengthy discussions on the Boost list last Winter we talked about
higher levels of functionality, but always bogged down in details. The
proposed library provides a toolkit; higher level functions can be built on
top of it if you can get people to agree just what they are.

>One may ask why you need a directory_list, when you could simply have a
>make_directory_list() (with the overloads shown above for the
>and returning a list<fs::path>. The answer is that I really like lazy
>evaluation for directory browsing (especially when dealing with subdir
>recursion). A simple make_directory_list() would have to browse all the
>files to create a complete list<fs::path>, while a directory_list can be
>"constructed" on the fly, when the elements are requested by the user.

The current fs::directory_iterator is "on-the-fly" in the sense that is how
it calls the operating system functions which do the actual work. But how
the operating system performs the actual directory access is completely out
of the control of the directory_iterator implementor, or any similar
library for that matter. The Filesystem Library doesn't ask implementors to
rewrite the operating system or make other heroic efforts.

Thanks for the comments. I'll try to review the FAQ a bit to make sure
they are covered there.


Boost list run by bdawes at, gregod at, cpdaniel at, john at