What are the Best Components of Boost? [closed]

Question

I've been browsing revision 1.38.0 of the Boost libraries, in an attempt to decide if there are enough jewels there to justify negotiating my company's external software approval process. In the course of writing test programs and reading the documents, I've reached a couple conclusions

• of course, not everything in Boost will ever be of use in my engineering group
• more importantly, some of these libraries seem more polished than others

In fact, some libraries seem a bit toy-like to me.

There are a number of fairly accessible libraries that I can see putting to use after only a short period of investigation, such as boost::variant (I really like the visitor component and the fact that the compiler barfs if a visitor lacks an operator for one of the variant types). I'd use boost::shared_ptr except for the fact that our group already has a set of smart pointer types.

So based on the broad experience of Stack Overflow users, which Boost libraries

• have high quality?
• are more than toys?
• are there any which have a high entry barrier but which are well worth learning?

Note that this is a somewhat different question than that posed in Boost considered harmful?

P.S. - Has one of the answers (from litb) been deleted? I can't see it here, and only an excerpt on my user page...

Answer 1

I use quite frequently (and it makes my life simpler):

• smart pointers (shared_ptr, scoped_ptr, weak_ptr, interprocess unique_ptr):

  • scoped_ptr for basic RAII (without shared ownership and ownership transfer), at no cost.
  • shared_ptr for more complex operations - when shared ownership is needed. However there is some cost.
  • unique_ptr - there is active work at boost on unifying various approaches (present at Boost) to unique_ptr with move emulation.
  • They are really simple to use (header only), easy to learn and very well tested (well, except maybe the unique_ptr)

• Boost Thread - actively developed (threads are now movable) library for working with threads. Hides the complexity of thread implementation on a given platform.

• Boost MPL and Fusion - these are more difficult to explain. For long time I didn't use compile time power, but after some reading and learning it turned out that some of my code can be nicely simplified. Still, beware of the compilation time...

• Boost Asio

  • Contrary to the first impression (at least some time ago) it is not only the networking library. It provides asynchronous I/O model that can be used for virtually anything.

• Boost Format (powerful output formatting, but very heavy)

• Boost Spirit2x (Karma and Qi used both for parsing and generating output based on a given grammar). Really powerful, can create a parser without resorting to external tools. Yet the compilation time might be a problem. Also version 2x is being actively developed and the documentation is rather scarce (the spirit-devel mailing list is very helpful though)

• Boost Bind, Function and Lambda to make your life easier and Boost Phoenix - just to experiment

• lexical_cast (something similar might be born soon as boost::string)

• Regex/Xpressive - regular expressions

• Type traits and concept checks - once again to make your life easier

• Math:

  • various random number generators
  • various statistical distributions
  • ublas - for using LAPACK/BLAS bindings in C++ like way
  • some mathematical functions, normally not available in C++
  • some tools for controlling the conversions between numreric types
  • interval arithmetics

• Boost Iterator (specialized adaptors for iterators and facade for creating your own)

• Boost Unit Testing framework

And still there are some parts that I'd barely touched in Boost. Probably I also forgot to mention few obvious ones.

Remember to use right tools (hammers) for right problems (nails). Remember to keep the solutions simple. Remember about the cost of received functionality (for example shared_ptr or boost::format runtime overhead or MPL/Fusion/Spirit/Phoenix compile time costs and executable sizes). But experiment and learn - it's where the fun is.

And when it comes to convincing the management to use the new libraries - you don't have to start with all the libraries. Start with the simple things (probably the ones that have a long and stable Boost history, broad compiler support, are planned for inclusion in TR2/C++1x, etc) and simple examples that show the benefits.

Answer 2

I found boost to be an uncontested must-have when designing cross-platform (e.g. *nix and win32) multi-threaded apps (boost::thread, boost::interprocess.) This alone has been justification enough in at least one instance for adopting boost as part of my employers' projects.

The rest (containers, generic programming and meta-programming, memory) followed as freebies.