[boost] RealNetworks is using boost

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

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