"Sebastien Martel" <smartel@real.com> wrote in message news:10209316.20050606121609@real.com...
boost.filesystem Not so happy here. This library looks promising, but there are a sum of little issues that makes me wonder if I should avoid using it in the future. 1- There is a bug on win98 when iterating a root drive. I sent a mail
[http://lists.boost.org/MailArchives/boost-users/msg10391.php] about the problem on boost-users with a fix and never received a response. I might get better results by rephrasing the mail.
Oops! That one got dropped. I'd attack it first thing tomorrow morning.
2- short-hand to build native paths using operator "/" is broken if you don't set the default name check to boost::filesystem::native. 3- What we really need is the reverse of the default library mode : have the library always work with native name-check and at the programmer's control, switch it to portable paths. There are WAY too many cases where we want to only work in native mode and portable path is the exception.
Those two problems disappear in the i18n version, which is about ready for a mini-review.
4- Lack of wstring/unicode support will become a problem very soon.
That also gets fixed in the i18n version (currently in CVS on the branch "i18n")
6- as noted in the do-list : "Windows: Some files seem to be poisoned to the point where you can't even do is_directory() on them without an access error. For example, pagefile.sys. Should directory_iterator ignore these files?" This is really a problem. A user must be very careful for exceptions when using iterators. They will throw.
The problem is a bit different than orignially thought - it actually relates more to the predicate functions like exists(), is_directory(), etc. As a part of the i18n review, those functions have been better defined, and several new functions (status(), etc.) provided. These additions give finer grain control over how errors are dealth with, so that it is easier to avoid exceptions if explicit error testing makes more sense for a particular application.
Overall this library, in it's current state, isn't a good fit for us.
Too bad! Hopefully you will find the i18n upgrade addresses most or all of your concerns. And you aren't alone, lots of others had similar concerns, and that's why a lot of effort has gone into addressing them for the i18n release (which presumably will go in Boost 1.34.) Thanks for your comments, --Beman