Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-06-06 21:10:38

"Sebastien Martel" <smartel_at_[hidden]> wrote in message

> 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
> [] 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

> 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

> 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

> 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,


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