Many thanks for the info, some of your comments are a little verbose to include wholesale on the web page, but I think we can use quite a few. I have a few comments on your comments as well if you'll bare with me:
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. 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.
I think that's going to be fixed soon.
4- Lack of wstring/unicode support will become a problem very soon.
Likewise.
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.
It looks like a lot of the problems can be summed up by "The Windows filesystem API's have lots of gotchas, and the Boost folks haven't dealt with them all yet." Are there other libraries that do better that we can learn from (does .NET handle it better for example?), is the current state better than a (quite possibly naive) "do it yourself" approach?
boost.date_time Simple to use, effective, does the job. I love the flexible input string parsing facilities, and the human readable ISO output. I created utilities to tie in with boost.filesystem so I can perform date_time calculations on files.
That's on my wish list as well, care to make it a submission?
Also had to create a layer to interface nicely with native locale date/time conversions api. I am sure every users of date_time that had to build UI apps ended up writing similar facilities.
Again, if it's a common problem, why not share if you can?
boost.array boost.optional Originally considered to implement an interface to value access of an embedded database but was discarded because of the _horrible_ compile times that appeared when introduced. Also considered for its visitation facility as a means to transport complex data to be rendered in UI controls. Again, dropped because of the compile times.
I'm not sure if these comments apply to array as well as optional (I'd be very surprised if it does, it's a pretty lightweight header). For optional: have you tried separate file template compilation (by declaring the templates you're using as "extern" in VC++ or g++)? I realise it sucks as a workaround, but compile times can really benefit enormously.
boost.thread Used to implement the monitor pattern in key areas. The 2 most desired features : static linking of boost.threads and ability to kill a thread.
Static linking is fixed, killing threads is much harder. Thanks for the feedback, John.