From: Sebastien Martel (smartel_at_[hidden])
Date: 2005-06-06 14:16:09
Name of the product:
Name of the company:
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:
Boost libraries used used with comments:
Boost.Format is top notch. Using it is a bliss.
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
These three libraries, along with smart pointer are
the most used in our application. I could not imagine
not having them handy.
Hands down, the most useful, and used library of
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
1- There is a bug on win98 when iterating a root
drive. I sent a mail
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
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
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.
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.
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.
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.
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.
When you need it, it works magic.
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.
Used to implement repetitive unit-test
code generation. The codebase benefited
greatly from the clarity boost.preprocessor
-- Best regards, Sebastien mailto:smartel_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk