Boost logo

Boost :

From: Sebastien Martel (smartel_at_[hidden])
Date: 2005-06-06 14:16:09

Hello boosters,

Name of the product:

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:

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
                     the lot!
                      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
                      [] 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
                      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.
                     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, gregod at, cpdaniel at, john at