[boost] Filesystem Review

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here is my review of the filesystem library.

Vote
- ------

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.

Details:
- ---------

- - 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: [phone] - 4273, fax: [phone]
http://www.ive.uni-hannover.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9jvqk0ds/gS3XsBoRAl6GAKCP11s6Zhgp5nBIgPgMyxZJbWOCMwCdFSBD
4LjPOc87BH6VAXXoUE/I2Zc=
=CBmg
-----END PGP SIGNATURE-----