Boost logo

Boost :

From: Thomas Witt (witt_at_[hidden])
Date: 2002-09-23 06:27:25

Hash: SHA1

Here is my review of the filesystem library.

- ------

I vote for acceptance of the library into boost.

Overall comments:
- ------------------------

I think the design of the library is carefully crafted. Beman did a great job
in exploring the different design alternatives and coming up with something
usable and extendable. With respect to usabillity. I am using the filesystem
library for a few weeks now on both windows and linux systems. Neither did I
hit a brick wall so far nor was using the library inconvenient.

There have been several requests for extensions of the library. I think it is
important to note that AFAICT non of these will break the library design.
Though I support some of these extension requests I do not think that they
need to be implemented before the library is accepted. From my own experience
I can say that the library is usable in its current state.

- ---------

- - Design

I am very sceptic with regard to the implicit conversion string <-> path. I
did not have the time to evaluate it in detail but if I had to vote now I
would disallow it.

I do not like the change in remove semantics. I preferred the throwing
variant, but I am not religous about this.

I still like my ideas about root :-).

I think Vladimir Prus has a point with his comments regarding exceptions. I do
not think that the filesystem library should hide filesystem limitations with
respect to rename, but the user should be able to act accordingly.

- -Implementation

As stated earlier the iterator implementation needs to be fixed.
I am not an expert in WIN32/POSIX API programming so I will not comment on the
use of the API.

- - Documentation

remove_all should be documented.

Further development:
- ---------------------------

I do believe the scope of the library should be broadened (does this make
sense?). Limiting the scope to script like operations has the danger of being
almost usable in the majority of applications.

As mentioned by others before file/directory property support would be a
worthwile extension.

I strongly believe that C++ has to provide better i18n support. With respect
to this I do not buy the arguments regarding wchar_t support. There are quite
a few non latin languages in the world and the need to support them is ever
increasing. Either C++ does something about this problem or application
programming will not be done using stdc++.

Last but not least, thanks Beman for all the work.

- --Thomas

- --
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


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