Learning Boost C++ Libraries: Solve practical programming problems using powerful, portable, and expressive libraries from Boost

You should be able to build Boost on most major Linux distributions. I use a Lubuntu 14.04 32-bit installation with GCC 4.8.1 and Clang 3.4. You can possibly build on much older distributions, as the Boost website lists GCC 3.3 as the minimum supported version. If you also want good C++11 support, use GCC 4.8 or higher.

If you want to use Clang instead of GCC, the recommended version is 3.4 or higher. Here are the required packages on Ubuntu:

You should be able to build Boost on Visual Studio 7.1 upwards. I use Visual Studio 2013 on a Windows 7 64-bit installation:

I would also recommend installing 7-Zip on Windows to extract Boost sources from the .7z or .tar.bz2 archives, which offer much better compression than the .zip archives.

As part of our day-to-day development work using Boost, we would need access to Boost's header files and Boost's libraries. A vast number of Boost libraries are header-only, which means that you just need to include the appropriate headers and build your sources. Some others have to be built into binary libraries that can be linked statically or dynamically to your application.

If we build from source, we will first identify a directory on our development machine, where we would like to install these files. The choice is arbitrary, but we can follow conventions if they exist. So on Linux, we can choose to install the library headers and binaries under /opt/boost. On Windows, this could be f:\code\libraries\Boost. You are free to choose different paths, just avoid spaces within them for less hassle.

Boost library binaries can have names that are difficult to decipher at first. So, we shall learn about what goes into naming the libraries. Library names have different layouts. Depending on the layout, different components are added to the base name in order to identify different facets of the library's binary compatibility and functionality.

Each library, whether static or shared, is named according to a well-defined scheme. The name of a library can be split into several components, not all of which are mandatory:

How a library name is made up of its components determines its name layout. There are three kinds of name layouts supported by Boost: versioned, system, and tagged.

On Microsoft Windows and several distributions of Linux, you can install a binary distribution of the Boost libraries. The following table lists the methods of installing Boost on some of the popular operating systems:

sudo apt-get install libboost-all-dev

sudo yum install boost-devel

Installing a binary distribution is convenient because it is the fastest way to be up and running.

$ sudo apt-get install libboost-all-dev

$ sudo yum install boost-devel

Building the Boost libraries from source offers more flexibility, as it is easy to customize the build, use alternative compilers/toolchains, and change the default name layout like we plan to. We shall build the Boost libraries from a source archive downloaded from the Boost website http://www.boost.org or http://sourceforge.net/projects/boost. I prefer the 7-Zip or the bzip2 archives, as they have the best compression ratios. We will use Boost libraries Version 1.57, and we will look at building them only on Linux and Windows operating systems.

If you have installed Boost in a nonstandard location (which is typically the case if you have not installed it from a native package), then you will need to make sure that your preprocessor can find the Boost header files you have included using the –I option in the compiler:

$ g++ -c chkfile.cpp -I/opt/boost/include -std=c++11

This step will create an object file called chkfile.o, which we will link to the binary. You can specify which library to link to using the -l option. In case of a nonstandard installation, you will need to ensure that the linker can find the path to the library you want to link against using the -L option:

$ g++ chkfile.o -o chkfile -L/opt/boost/lib -lboost_filesystem-mt -lboost_system-mt -std=c++11

The preceding command line will work for either a static or a shared library. However, if both types of library are found, it will use the shared version. You can override this with appropriate linker options:

$ g++ chkfile.o -o chkfile -L/opt/boost/lib -Wl,-Bstatic -lboost_filesystem-mt -Wl,-Bdynamic -lboost_system-mt -std=c++11

In the preceding case, the filesystem library is linked statically while others are linked dynamically. The -Wl switch is used to pass its arguments to the linker. In this case, it passes the -Bstatic and -Bdynamic switches.

If it is a shared library that you link against, then at runtime the dynamic linker needs to locate the shared library and load it too. The way to ensure this varies from one version of Unix to the other. One way to ensure this is to embed a search path in your executable using the rpath linker directive:

$ g++ -o chkfile chkfile.o -L/opt/boost/lib -lboost_filesystem-mt -lboost_system-mt -Wl,-rpath,/opt/boost/lib:/usr/lib/boost -std=c++11

On the target system, where the binary mytest is run, the dynamic linker would look for the filesystem and system shared libraries under /opt/boost/lib and /usr/lib/boost.

Other ways besides using the rpath mechanism also exist. Linux uses a utility called ldconfig to locate shared libraries and update search paths. For more details, look at the man pages for ldconfig (8). On Solaris, the crle utility performs a similar action.

Using the Visual Studio IDE, we will have to tweak certain project settings in order to link against the Boost libraries.

First, ensure that your compiler is able to find the necessary header files:

If you built your Boost libraries on Windows with the default layout (versioned), this is all you will need to do for linking correctly. If we use the tagged layout, we must also define a second preprocessor symbol BOOST_AUTO_LINK_TAGGED. If we use system layout for naming, we will need to define BOOST_AUTO_LINK_NOMANGLE instead. You will get a linker error without these definitions:

You should now be able to build your project from your IDE without any problems. In order to run your program, the dynamic linker must be able to locate the dynamic library. To take care of this, on Windows, you can add the path of your Boost libraries to the PATH environment variable. For running your programs from within the IDE, you can add the path of your Boost libraries to the PATH variable by navigating to Debugging | Environment, as shown in the following screenshot:

In order to build the examples, you need to install CMake, which is one of the most popular cross-platform build tools for C++ programs. With CMake, you can easily generate a build system of your choice on an operating system of your choice, using a single set of CMake specifications.

You can download a binary package for CMake from www.cmake.org, or download a source archive and build it on a platform of your choice.

Download the source code archive and extract it to a directory on your development machine. The layout of the extracted directory would look like this:

The source code archive available for download contains separate directories for each chapter. Within each chapter directory, you will find the complete source code for each example. The source code files are named based on the listing identifier.

A listing identifier is a unique tag used for examples in this book, as shown in the following screenshot:

Here, the listing identifier is Listing 11.18 and indicates that this is the eighteenth example in Chapter 11, Network Programming Using Boost Asio. Therefore, in the ch11 folder, you will find listing11_18.cpp, which contains the asynchronous UDP server example that appears in Chapter 11, Network Programming Using Boost Asio. In some cases, a big example is broken down into multiple listings in the text, but they all form part of the same source file. In such cases the listings are tagged with letters; for example, listing 7.22a, 7.22b, 7.22c, and so on. You can still expect a file called listing7_22.cpp, which combines the code from these listings.

In order to build all the examples in this book, you need to follow these steps:

We do not cover CMake in this book. It is worth exploring CMake further on your own, and a great place to get started is the CMake Wiki (http://www.cmake.org/Wiki/CMake).