Boost is a free library which is aimed at providing quality software components to developers, whilst using the styles of the Standard Template Library. Some of the components within the library may be put forward as future extensions to the Standard Library.

The Boost homepage contains extensive documentation on all of the individual components. This article is intended to be an overview of why you should consider using Boost, and the Boost components in preference to other libraries, and to provide a location on CodeProject which can offer links to related documentation.

Boost installation is simple because most of the components within the library reside in their own header files, which should not require modification. The BoostJam build tool is available for the components which do require compilation.

Unzip the entire archive into a directory of your choosing. To start using the components add the Boost directory which includes version numbers to your include path. For the current version of Boost, boost_1_30_0.

Boost supports a variety of compilers, operating systems and standard libraries. It provides workarounds for the broken features of many compilers, perhaps the most significant being the workarounds for problems with templates, including partial template specialisation and member template friends.

Regression testing. Each update to Boost is heavily regression tested, and the status of the library for all compilers is freely available.

Many of the people involved with the development of the C++ standard are involved with Boost.

Simple to install and upgrade. In most cases, installation and upgrading only requires the addition or change of one include path.

Easy to configure. Compilation options can be specified by changing directives in one or two header files.

What follows is a minimal listing of components. There are about 50 major sub-components in Boost at the moment. The following components were those that I felt logically progressed from the components in the STL, were easy to integrate, or were especially significant to most programmers.

Smart pointers are tools that prevent resource leaks (especially in the presence of exceptions), promote the concept of 'Initialisation is Resource Acquisition'. They emulate, to a certain extent, garbage collection like behaviour.

Most of the limitation of std::auto_ptr are relatively well known:

std::auto_ptr's cannot be stored within a standard containers.

std::auto_ptr's cannot (easily) be used to implement the pImpl (pointer-to-implementation) idiom.

std::auto_ptr does not work with arrays.

The 5 types of Boost smart pointers overcome these flaws and provide many extra features.

Functors and binders have become a common part of using the STL, but using most standard library implementations it can still be difficult to combine multiple functions. Composers allow functors to be combined in several ways, minimising the amount of times that users have to write their own loops.

A component which provides a type safe way to move any type of component, without having to rely upon void pointers or unions. The design principles for this component is at least as significant as the component itself (derivation of a template class from a non template base class). Something similar to boost::any appears in Alexandrescu’s Modern C++ Design in the guise of Functors and Functor Implementations.

The lambda library provides a shortcut for producing binders, functors and composers using expression templates. My personal opinion on the library is that developers would need some practice to recognise it’s use. Libraries like the Lambda library are probably the way of the future for C++, but at the moment, I think I’m prepared to have slower uglier code that I know the next guy can understand.

The Boost Lambda Library IndexFurther information on the basics of expression templates was published in the March issue of the C/C++ users journal (C++ Expression Templates – Angelika Langer and Klaus Kreft)

The BGL is a huge library, with a large amount of support material and good sample programs. “The Boost Graph Library, The: User Guide and Reference Manual” has been published by Addison-Wesley in the C++ In Depth Series (The same fantastic series that includes 'Exceptional C++', 'More Exceptional C++' and 'Modern C++ Design'), which I believe is testament to the quality of the library.

Developed by Code Project regular William E. Kempf, the threads library makes it seem almost as easy to do threads in C++ as it is in Java. It requires linking to an additional library, built with BoostJam.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Share

About the Author

Andrew is a PhD student at Swinburne University in Melbourne Australia, investigating the control systems of UUV's - Unmanned Underwater Vehicles. He graduated from Swinburne with a Bachelor of Engineering (Robotics and Mechatronics) and a Bachelor of Science(Computer Science & Software Engineering)

His practical experience includes a year developing an industrial computer vision system from scratch, and working as the software architect for the 2004 Swinburne Robocup team (f180 league).

I'm more than willing to add to this article or write additional material, I don't claim to be a Boost expert, but I've been working with it for a little while. I think that most of the documentation is OK, but sometimes it can be a bit hard to find what you're looking for - the standard of documentation varies significantly across components.

What type of things were you looking for in particular? Any particular components?

If you can keep you head when all about you
Are losing theirs and blaming it on you;
If you can dream - and not make dreams your master;
If you can think - and not make thoughts you aim;
Yours is the Earth and everything that's in it.

I was generally looking for more examples on how and where to use the library. I have looked into using boost code for a long time but when I read the examples I either don't understand what is happening or where someone would use it in a real world example. When I look at the pointers stuff. WOW there are so many types! I am not sure where to start. I use the smart pointer from the following article http://www.codeproject.com/cpp/smartptr.asp[^]

Does boost offer a better solution?

Also, is there any use for the threads library in a win32 application? To me it looks like you sacrifice performance and functionality for portability.

John M. Drescher wrote:I use the smart pointer from the following article http://www.codeproject.com/cpp/smartptr.asp

Stefan Chekanov's SmartPointer that you've been using is just different to the Boost Smart Pointers.

boost::shared_ptr and boost::shared_array offer reference counting, similar to Chekanov's 'RefCountPtr', the boost approach to thread safety varies away from the design in Chekanov's work.

The number of classes involved with the Boost smart pointers is probably less than you would expect, they are just spread around in lots of header files.

I haven't worked with Chekanov's classes so the following comments are from the short look that I've just had.

1/ It is likely that the class will not be able to uphold an exception safety guarantee. I'm not going to cite a specific example, nothing was glaring obvious, but proving exception guarantees is hard, very hard.

2/ The constructor which accepts a SmartPtrBase, which can be used to convert pointer types is likely to be risky if used inappropriately to convert the types of pointers (threaded -> non-threaded), which could allow incorrect access to a resource.

3/ The Boost Smart pointers reference counts will be safe in the presence of threads, however they do not aquire criticle sections (see the CSyncAccessRep class) so the contained object will not be safeguarded in multiple threads. This is perhaps the biggest difference, if you decide to change Smart Pointer implementations.

4/ Parameterization: Chekanov states that to avoid having to supply additional template parameters he provides the additional classes. All of the boost smart pointers have been designed to only take a single parameter (the type of the pointer).But Greg Colvin and Jerry Schwarz argued that "parameterization will discourage users", and in the end we choose to supply only the direct implementation
See: http://www.boost.org/libs/smart_ptr/smart_ptr.htm[^] for more information.
If you are looking for a full blown parameterization capable smart pointer, Loki (from 'Modern C++ Design' fame) has now received a large ammount of testing, and may be appropriate.

My personal opinion on smart pointers is that they are a must-have tool, but I'm only going to use something I know isn't going to fail in unexpected ways. Also, if I decide to change platforms, my code should require as little work as possible to port. Smart pointer code is one of the areas where I know that tiny changes can have a massive effect in the presence of exceptions, and proving that a solution is exception safe is a time consuming job. I'm willing to cede to the known experts in the field, Colvin, Abrahams, Dawes and Dimov along with all the other users and library writers that the boost smart pointers will 'just work' - no matter what.

If you can keep you head when all about you
Are losing theirs and blaming it on you;
If you can dream - and not make dreams your master;
If you can think - and not make thoughts you aim;
Yours is the Earth and everything that's in it.

John M. Drescher wrote:Also, is there any use for the threads library in a win32 application? To me it looks like you sacrifice performance and functionality for portability.

I'm not sure where functionality and performance losses could come from, but my knowledge of threading isn't the greatest. To me it looks like all the overhead is at construction / destruction of a thread object. I'm more than willing to trade that for being able to pass parameters into my function in a typesafe way (using function objects and binders), rather than attempting to cast void pointers.

I guess it's another example of 'adding an extra level of indirection' to solve a problem. If you can work easily with win32 threads then use that, it's the beauty of boost, you can pick and choose which bits you want,

If you can keep you head when all about you
Are losing theirs and blaming it on you;
If you can dream - and not make dreams your master;
If you can think - and not make thoughts you aim;
Yours is the Earth and everything that's in it.

How about Boost.function? Recently a article http://www.codeproject.com/cpp/CallbackDemo.asp[^] there was a suggestion to use Boost.function instead. I looked at the documentation and examples and have absolutly no idea about the usefulness of Boost.function and how I could use it to replace a callback mechanism.

Just a couple of comments on that particular article:
- The way the sample app is written makes it relatively hard to see what callbacks are doing
- Big chunks of the code aren't type safe (void pointers) - big mental alarm bells start ringing in my head, getting all the louder when I see C-style casts.
- Some of the functions should really be using standard library elements, without even considering boost.

In the cases where you're writing the code, it's generally easiest to specify that anything with function call semantics is acceptable. The simplest way to do that is to templatize all of the functions. STL does this, that's why all the STL algorithms are templatized. Function objects in the standard are meant to be light-weight, so the types shouldn't really be significant. The consequence of that is that it's hard to exchange global functions for member function pointers.

The following code, which is a rewrite of the mentioned article's sample code uses boost::bind. If the callback does not support a conversion to a string type, the build will fail.

The basic idea to remember is that a callback (for a member function) needs to have two things: first an object pointer (or reference) and second the member function pointer. Binding like this allows you to attach the object to the member function pointer, in this case most if not all of this should be possible without using boost, by just using standard library elements (the second part of my response isn't). What makes boost bind/function/mem_fn outstanding in this area is that you can have any number of arguments.

However, if you need a callback facility are you going to know the types involved? Most of the time the answer to that question is yes. [Slightly OT: As a student, that one concept took me months to get my head around, especially with so many templates whizzing around].

boost::function does this by letting you restrict the incoming types a bit better. Think of it as a flag to other programmers about what you are doing.

I built both samples under MSVC6, and noticed a degradation in compile time performance using boost::function.

If you can keep you head when all about you
Are losing theirs and blaming it on you;
If you can dream - and not make dreams your master;
If you can think - and not make thoughts you aim;
Yours is the Earth and everything that's in it.

I've been considering writing an article about some Boost features myself - this is a great start Andrew, thanks!

It's always surprising to me that many of my colleagues don't know or use Boost as it's a terrific resource.

If anyone would like more information about some of the specific functionality that Boost provides then I also extend the safe offer as Andrew - let us know what is of interest to you and we'll try and provide...

On a separate issue, it's always good to see Aussies contributing - particularly Victorians! It's just a shame that you chose Swinburne Andrew... (coming from a former RMIT'er)

MattyT wrote:It's always surprising to me that many of my colleagues don't know or use Boost as it's a terrific resource

I know of it but haven't used it yet. I think more people will use it over time as it becomes better known and documented. It was the same with STL. I knew of it a long time before I started using it - mainly because it took me a while before I understood how to use it.

Also, we must reckon with the following stages when encountering new technolgy (or, at least, they're common stages for me!)

1. Bafflement.
2. Understanding but then asking: but what's the point?
3. Encountering a problem(s) for which the new technology provides a tailor-made solution.

On comp.std.c++ Beman Dawes wrote:Of the 12 proposals accepted so far, 10 grew out of the Boost libraries.

With momentum like that behind the Boost, it seems to me like it can't be ignored - developers need to be aware that many of these components are, in addition to being 'top notch', likely to be adopted into the c++ Standard.

If you can keep you head when all about you
Are losing theirs and blaming it on you;
If you can dream - and not make dreams your master;
If you can think - and not make thoughts you aim;
Yours is the Earth and everything that's in it.

The key thing for me is usually point 3 in my post. I need to encounter a problem for which I can use the new technique (once I've understood how to use it). I don't usually use new stuff just for the sake of it. Especially, as others may have to maintain my code.

I think there just always will be some lag between what the average developer uses it and what's new. Even now many developers shy away from STL and stick to unnecessarily low-level, error-prone code. I know this from having done lots of maintenance programming recently, and not on really old code.

However, my main problem at the moment is finding any kind of work at all in the current market, having been out of work for most of the past couple of years. So Boost doesn't get me too excited just at the moment. Not to mention that, in the UK, C++ is bottom of the skills table and bottom of the rates table too! Not much of an incentive to invest time in learning quite demanding stuff.

Much like when I read Andrei Alexandrescu's book I found that being aware of new features and techniques really changed the way that you approach and solve problems. Suddenly you find your tools (the language) more flexible and solutions become more natural. I think I can smell an article about effective use of the Boost and Loki libraries coming up...

I can understand the job issues - we're facing similar problems here in Australia. But adding Boost knowledge to your repertoire can't hurt can it? It would certainly make me more likely to hire someone for a C++ role...

MattyT wrote:I found that being aware of new features and techniques really changed the way that you approach and solve problems. Suddenly you find your tools (the language) more flexible and solutions become more natural.

I certainly like to be aware of the latest ideas on a subject, even if I don't use them straight away (otherwise I wouldn't have read this article!). But new ideas aren't always easy to grasp. For example, STL seemed mysterious and complicated to me for some time.

There's also the fact that if you use something obscure you will baffle the majority of other developers who may have to maintain your code. Of course, at some point we've all got to move on. It's a question of striking a balance. I started using STL heavily after it had been around for some time and there were books on the subject. At that point I expected conscientious C++ developers to be using it, even if they weren't. And a lot of C++ developers still aren't!

The problem is that, looking at adverts for C++ jobs, things such as Boost are not requested. All of the complementary technolgies seem to have higher importance - ATL, COM, SQL Server, .NET.

MattyT wrote:would certainly make me more likely to hire someone for a C++ role...

There are all sorts of things I could add to my repertoire but it's a question of priorities. I think it's better to focus on things that are in demand in the marketplace which, from the way things are going in the UK, might soon be something other than programming!