Hello boosters, Name of the product: Rhapsody Name of the company: Real Networks Description of the Application and the Service: The Rhapsody Music Service allows its subscribers to legally download/transfer/burn over a million songs. The Rhapsody client software was built with many Boost libraries. URL of company and service: http://www.real.com/ Boost libraries used used with comments: boost.format Boost.Format is top notch. Using it is a bliss. boost.lexical_cast Quite useful. However pedantic use of streams to execute the conversions of basic types to/from strings is terrible. Had to be careful not to use in performance sensitive areas. I really wished there were a way to achieve performance comparable to c-runtime functions for ato* and *toa. boost.functional boost.function boost.bind These three libraries, along with smart pointer are the most used in our application. I could not imagine not having them handy. boost.smart_ptr Hands down, the most useful, and used library of the lot! 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. 4- Lack of wstring/unicode support will become a problem very soon. 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. Overall this library, in it's current state, isn't a good fit for us. 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. 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. boost.tokenizer I glad to use tokenizer when we had to parse a whole bunch of weirdly formatted strings. It is a little bit tricky to get used to, especially the fact that tokenizer acquires references to its input in some cases instead of making a local copy. IMO, boost.Tokenizer would benefit from a policy design to fix this issue. I would prefer Tokenizer making a true copy of its input by default. boost.iterators Wow. Moving legacy iterating interfaces, or interfaces that should of been properly designed as iterators to STL compliant iterators was easy and painless. The gains in functionality to our code made by this library are invaluable. 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. boost.regex When you need it, it works magic. 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. boost.preprocessor Used to implement repetitive unit-test code generation. The codebase benefited greatly from the clarity boost.preprocessor brought. -- Best regards, Sebastien mailto:smartel@real.com
"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
"Beman Dawes" <bdawes@acm.org> wrote in message news:d82veo$tqa$1@sea.gmane.org...
"Sebastien Martel" <smartel@real.com> wrote in message news:10209316.20050606121609@real.com...
boost.filesystem 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.
Fixed in CVS. Please let me know if it is still a problem - I don't have access to a Win98 machine for testing. --Beman
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.
participants (3)
-
Beman Dawes -
John Maddock -
Sebastien Martel