Frequently Asked Questions

After installing the Boost libraries, not much, just include the libraries you want. Here is an example (example1.cpp) using Boost.Multiprecision:

Compile with:

No linking is required, just run the program!

Using a compiled-binary library involves linking to the library, and any dependent libraries that are also compiled. Here is an example (example2.cpp) using Boost.Filesystem.

This requires an extra step before running, linking to both Boost.Filesystem and Boost.System. We need to link to Boost.System because Boost.Filesystem calls boost::system::generic_category() - for error handling - and this call is only defined in the compiled version of Boost.System:

Now you can run your program.

Depends on your priorities:

Also, with a header-only library the compiler has full visibility of the code, allowing inlining and optimizations that might not be possible with separately compiled binaries. This can reduce function call overhead when optimizations are applied. Since no precompiled binaries are needed, projects using header-only libraries are easier to distribute and deploy.

However, header-only libraries are compiled within each project, so any minor changes (even updates) can lead to unexpected behavior due to template changes. Shared libraries with well-defined Application Binary Interfaces (ABIs) offer better versioning control.

Header-only libraries are certainly easier to get going with. To optimize for better stability and debugging, and reducing binary size, refer to the next few questions on how to create binaries for header-only code - typically, when your project is becoming stable.

Yes, with C++20 modules, you can precompile header-only libraries into a binary module and import them when needed. This significantly reduces compile times. Start by creating a module interface unit (say, boost_module.cppm) that includes the header-only Boost libraries. For example:

Now, compile the module:

Then, reference the precompiled module in another file:

Compile and link:

Yes, even if the library is header-only, you can wrap it in a .cpp file, compile it into a static .a or .lib file, and link it. Start by creating a wrapper source file (boost_wrapper.cpp) that includes the header-only Boost libraries:

Now, compile it into a static library:

Use it in your code:

Compile and link:

Yes, a precompiled header should enable faster recompilation when only the main code changes. And, unlike modules, it works in older C++ versions.

For example, create an hpp file (boost_pch.hpp) containing the required libraries:

Precompile it into a .gch file:

Use it in your code:

Typically, when your project starts becoming "large" use of compiled libraries becomes more relevant.

While not perfect, lines of code is a quick way to classify project sizes:

Or possibly classify a project by the number of developers:

There are other metrics too - if your incremental build takes minutes, it’s getting large. If a full rebuild takes hours, it’s definitely a large project. If the dependency tree is deep, requiring fine-grained modularization, it’s large.

A coding project becomes a beast when two or more of the following conditions are met:

Many Boost libraries are designed to be modular, yet complementary, and over the years, developers have discovered powerful combinations of libraries that work well together. Here are some groups:

Desktop applications like text editors, project managers and utilities often need cross-platform compatibility, user input processing, and dynamic plugins via signal-slot mechanisms. Consider Boost.Filesystem to provide the file management, Boost.Locale for use in multiple regions, Boost.Signals2 to support an event system, and Boost.Regex for structured text parsing.

Not in a broad sense, Boost C++ libraries are designed with a high degree of interoperability. However, there are always nuances when multiple libraries have overlapping functionality, conflicting macros, or different assumptions about thread safety, memory management, or initialization. Issues can usually be avoided with careful design, for example:

The following checklist should be a good start:

Boost C++ Library Integration Checklist

Yes, Boost is designed to work with your existing C++ code. You can add Boost libraries to any project that uses a compatible C++ compiler.

Yes, Boost libraries are designed to work with modern C++ standards including C++11, C++14, C++17, C++20, and C++23.

Boost libraries are generally compatible with most Linux distributions, provided that the distribution has an up-to-date C++ compiler. This includes:

While Boost strives to ensure compatibility with a wide range of compilers and systems, not every library may work perfectly with every system or compiler due to the inherent complexities of software. The most reliable source of information is the specific Boost library’s documentation.

Boost provides Boost.Test for unit testing, which can be an integral part of the debugging process. It also provides the Boost.Stacktrace library that can be used to produce useful debug information during a crash or from a running application. Refer also to Category: Correctness and testing.

Boost uses its own set of assertion macros. By default, BOOST_ASSERT is enabled, but if it fails, it only calls abort(). If you define BOOST_ENABLE_ASSERT_HANDLER before including any Boost header, then you need to supply boost::assertion_failed(msg, code, file, line) and boost::assertion_failed_msg(msg, code, file, line) functions to handle failed assertions.

You can use the Boost.Stacktrace library to obtain a stack trace in your application. You can capture and print stack traces in your catch blocks, in signal handlers, or anywhere in your program where you need to trace the execution path.

Yes, Boost libraries can be used with common debuggers like GDB or Visual Studio. You can set breakpoints in your code, inspect variables, and execute code step by step. Boost doesn’t interfere with these debugging tools.

Boost doesn’t provide a debugger itself. The libraries tend to make heavy use of assertions to catch programming errors, and they often provide clear and detailed error messages when something goes wrong.

Boost provides the assertion boost::assert. Best practices when using this are:

In the context of this FAQ, a dependency is any other library, Boost or Standard or third-party, that a Boost library requires. A primary dependency is a library the top-level library explicitly includes, a secondary dependency is a library that one of the primary, or other secondary dependency, includes.

Boost libraries are modular, but they can depend on each other for various functionalities - for example, Boost.Asio relies on Boost.System for error codes.

In general, taking dependencies can add a lot of value and reduce development time considerably. Boost libraries are carefully reviewed and tested to minimize dependency issues.

As often with powerful concepts, there are pitfalls. Dependencies can lead to "dependency chains," where including one library pulls in others that may not be needed by your project.

This includes handling several awkward situations: Version Conflicts - when different dependencies require incompatible versions of the same library, Transitive Dependencies - when a library pulls in additional, indirect dependencies that you may not even realize are part of your project, Bloat - when the sheer number of dependencies makes the build or runtime environment large, slow, or error-prone, and Security Risks - when outdated or unnecessary dependencies introduce vulnerabilities.

In forum posts you might come across the following phrases, each describing a frustration with dependencies:

A standalone library is one where there are no dependencies (or, in reality, few), or the library depends only on the C++ Standard Library. Sometimes separate standalone versions of specific libraries are available, though they might be lightweight versions and not have parity of functionality with the non-standalone version.

A simple question but with a non-trivial answer. Consider working through this list of strategies and carefully applying when you can:

Yes, the Boost Copy Tool (bcp) is designed to help with dependency management. It allows you to extract a subset of the libraries and their dependencies into a separate directory, minimizing what gets pulled into your project. Install the tool and run bcp [library-name] [output-dir]. Review the output directory to ensure that only the necessary dependencies are included. For example, if you’re using Boost.Regex, enter bcp regex ./boost_subset and review the contents of your ./boost_subset directory.

There is also the Boost Dependency Report, which goes into detail on the primary and secondary dependencies of all the libraries.

You can use static analysis tools, like Clang-Tidy or Cppcheck, to analyze your application and see which parts of any dependency are actually being used. Once identified, you can both remove unnecessary headers or dependencies, and perhaps rewrite portions of your code to avoid unnecessary functionality.

The library authors are responsible for all the documentation specific to their library. The authors are clearly the most knowledgeable on the design decisions, architecture, API calls, inner workings, and potential limitations of their library. Contributor guidelines on documentation help maintain consistency in styling and content across the library collection. Refer to Documentation Guidelines.

Yes you can, file an issue on the library. Typically library authors welcome feedback that enhances the useability of their work - refer to Reporting Issues.

There is no formal localization of library documentation. However, translation efforts have existed at various times for Japanese, Chinese and Russian. Most current effort is into Japanese - refer to boostjp.

The copyright ownership of library documentation remains with the documentation authors. Contact the authors via the Boost Developers Mailing List if you are inspired to take on this task.

Not for the Boost libraries. Microsoft did experiment with localized API calls many years ago, though the project was abandoned as way too complicated, unmaintainable, and not particularly useful.

Members of PL22.16 (the INCITS/ANSI committee) or of JTC1/SC22/WG21 - The C++ Standards Committee - ISOCPP member country committee (the "national body" in ISO-speak), can attend the meetings. You can also attend as a guest, or join in remotely through email. For details and contact information refer to Meetings and Participation.

INCITS has broadened PL22.16 membership requirements so anyone can join, regardless of nationality or employer, though there is a fee. Refer to Apply for Membership.

It is recommended that any non-member who would like to attend should check in with the PL22.16 chair or head of their national delegation. Boosters who are active on the committee can help smooth the way, so consider contacting the Boost developers' mailing list providing details of your interests.

There are three meetings a year. Two are usually in North America, and one is usually outside North America. See Upcoming Meetings. Detailed information about a particular meeting, including hotel information, is usually provided in a paper appearing in one of mailings for the prior meeting. If there isn’t a link to it on the Meetings web page, you will have to go to the committee’s C++ Standards Committee Papers page and search a bit.

No, but there can be a lot of incidental expenses like travel, lodging, and meals.

The meetings typically start at 9:00AM on Monday, and 8:30AM other days. It is best to arrive a half-hour early to grab a good seat, some coffee, tea, or donuts, and to say hello to people.

Until the next standard ships most meetings are running through Saturday, although some end on Friday. The last day, the meeting is generally over much earlier than on other days. Because the last day’s formal meeting is for formal votes only, it is primarily of interest only to actual committee members.

Sometimes there are evening technical sessions; the details aren’t usually available until the Monday morning meeting. There may be a reception one evening, and, yes, significant others are invited. Again, details usually become available Monday morning.

Monday morning an hour or two is spent in full committee on admin trivia, and then the committee breaks up into working groups (Core, Library, and Enhancements). The full committee also gets together later in the week to hear working group progress reports.

The working groups are where most technical activities take place. Each active issue that appears on an issues list is discussed, as are papers from the mailing. Most issues are non-controversial and disposed of in a few minutes. Technical discussions are often led by long-term committee members, often referring to past decisions or longstanding working group practice. Sometimes a controversy erupts. It takes first-time attendees awhile to understand the discussions and how decisions are actually made. The working group chairperson moderates.

Sometimes straw polls are taken. In a straw poll anyone attending can vote, in contrast to the formal votes taken by the full committee, where only voting members can vote.

Lunch break is an hour and a half. Informal subgroups often lunch together; a lot of technical problems are discussed or actually solved at lunch, or later at dinner. In many ways these discussions involving only a few people are the most interesting. Sometimes during the regular meetings, a working group chair will break off a sub-group to tackle a difficult problem.

No, and committee members on tight budgets often stay at other, cheaper, hotels. The venue hotels are usually chosen because they have large meeting rooms available, and thus tend to be pricey. The advantage of staying at the venue hotel is that it is then easier to participate in the off-line discussions, which can be at least as interesting as what actually happens in the scheduled meetings.

Programmer casual. No neckties to be seen.

It is almost essential to have a laptop computer. There is a meeting wiki and there is internet connectivity. Wireless connectivity has become the norm.

It is helpful to have downloaded the mailing or individual papers for the meeting, and to have read any papers you are interested in. Familiarize yourself with the issues lists. Decide which of the working groups you want to attend.

An electronic document containing issues, proposals, or anything else the committee is interested in. Very little gets discussed at a meeting, much less acted upon, unless it is presented in a paper. Papers are available to anyone. Papers don’t just appear randomly; they become available four (lately six) times a year, before and after each meeting. Committee members often refer to a paper by saying what mailing it was in, for example: "See the pre-Redmond mailing."

A mailing is the set of papers prepared before and after each meeting, or between meetings. It is physically just a .zip or .gz archive of all the papers for a meeting. Although the mailing’s archive file itself is only available to committee members and technical experts, the contents (except copies of the standard) are available to all as individual papers. The ways of ISO are inscrutable.

The committee’s mailing lists are called "reflectors". There are a number of them; "all", "core", "lib", and "ext" are the main ones. As a courtesy, Boost technical experts can be added to committee reflectors at the request of a committee member.

Smart pointers are a feature of C++ that Boost provides in its Boost.SmartPtr library. They are objects that manage the lifetime of other objects, automatically deleting the managed object when it is no longer needed. See the Smart Pointers section.

Yes, Boost.Test is the unit testing framework provided by Boost. It includes tools for creating test cases, test suites, and for handling expected and unexpected exceptions. Refer to Testing and Debugging.

Boost.Asio is a library that provides support for asynchronous input/output (I/O), a programming concept that allows operations to be executed without blocking the execution of the rest of the program.

Boost.Mp11 (MetaProgramming Library for C++11) is a Boost library designed to bring powerful metaprogramming capabilities to C++ programs. It includes a variety of templates that can be used to perform compile-time computations and manipulations. Refer to Metaprogramming.

Yes, Boost.Thread provides a C++ interface for creating and managing threads, as well as primitives for synchronization and inter-thread communication. In addition, Boost.Atomic provides atomic operations and memory ordering primitives for working with shared data in multi-threaded environments. Boost.Lockfree provides lock-free data structures and algorithms for concurrent programming, allowing multiple threads to access shared data concurrently without explicit synchronization using locks or mutexes. For a lighter approach to multi-threading, consider Boost.Fiber. Fibers offer a high-level threading abstraction that allows developers to write asynchronous, non-blocking code with minimal overhead compared to traditional kernel threads.

Boost.Spirit is a library for building recursive-descent parsers directly in C++. It uses template metaprogramming techniques to generate parsing code at compile time. Refer to Metaprogramming.

Boost libraries offer a wide range of algorithmic and data structure support. Here are five libraries that you might find interesting:

Refer to Real-Time Simulation.

The Boost libraries are licensed under the Boost Software License, a permissive free software license that allows you to use, modify, and distribute the software under minimal restrictions. Refer to The Boost Software License.

Metaprogramming is a technique of programming that involves generating and manipulating programs. In the context of Boost and C++, metaprogramming often refers to template metaprogramming, which uses templates to perform computations at compile-time.

Boost.Mp11 is a Boost library designed for metaprogramming using C++11. It provides a set of templates and types for compile-time computations and manipulations, effectively extending the C++ template mechanism.

With Boost.Mp11, you can perform computations and logic at compile-time, thus reducing runtime overhead. For example, you can manipulate types, perform iterations, make decisions, and do other computations during the compilation phase.

A typelist is a compile-time container of types. It’s a fundamental concept in C++ template metaprogramming where operations are done at compile time rather than runtime, and types are manipulated in the same way that values are manipulated in regular programming.

In the context of the Boost.Mp11 library, a typelist is a template class that takes a variadic list of type parameters. Here’s an example:

In this example, my_typelist is a typelist containing the types int, float, and double. Once you have a typelist, you can manipulate it using the metaprogramming functions provided by the library. For example:

In these examples, mp_size is used to get the number of types in the list, mp_contains checks if a type is in the list, mp_push_back adds a type to the list, and mp_at_c retrieves a type at a specific index in the list. All these operations are done at compile time.

Metaprogramming with Boost.Mp11 can lead to complex and difficult-to-understand code, especially for programmers unfamiliar with the technique. Compile errors can be particularly cryptic due to the way templates are processed. Additionally, heavy use of templates can lead to longer compile times.

Other challenges include lack of runtime flexibility, as decisions are made at compile time. And perhaps issues with portability can occur (say, between compilers) as metaprogramming pushes the boundaries of a computer language to its limits.

Technically, Modular Boost consists of the Boost super-project and separate projects for each individual library in Boost. In terms of Git, the Boost super-project treats the individual libraries as submodules. Currently (early 2024) when the Boost libraries are downloaded and installed, the build organization does not match the modular arrangement of the Git super-project. This is largely a legacy issue, and there are advantages to the build layout matching the super-project layout. This concept, and the effort behind it, is known as "Modular Boost".

Refer to the Super-Project Layout topic (in the Contributor Guide) for a full description of the super-project.

No. The collection of libraries is still a single release, and there are no plans to change the release cadence.

Yes. Unfortunately there is one restriction that adhering to a modular Boost requires - there can be no sub-libraries. That is, we can’t support having libraries in the root/libs/<group name>/<library> format. All libraries must be single libraries under the root/libs directory. There’s only a handful of libraries that currently do not conform to this already (notably the root/libs/numeric/<name> group of libraries).

It’s easier on everyone if we adopt a flat hierarchy. The user will experience a consistent process no matter which libraries they want to use. Similarly for contributors, the creation process will be consistent. Also, tools can be written that can parse and analyze libraries without an awkward range of exceptions. This includes tools written by Boost contributors. For example, the tools that are used to determine library dependencies. And any tool that a user might want to write for their own, or shared, use.

Other advantages of a modular format include:

Correct - backwards-compatibility should be maintained.

An exact timeline requires issues to be resolved, though later in 2024 is the current plan-of-record.

Yes, developers have successfully used Boost libraries in applications written in languages other than C++ by leveraging language interoperability features and creating bindings or wrappers.

The most notable example is the use of Boost.Python, a library specifically designed to enable seamless interoperability between C++ and Python. Boost.Python allows developers to expose C++ classes, functions, and objects to Python, enabling the use of the libraries from Python code. This has been used extensively in scientific computing, game development, and other fields where the performance of C++ is combined with the ease of Python.

Here is an example, wrapping a C++ class for use with Boost.Python and including exception handling:

You need to compile this C++ code into a shared library that Python can load. Here’s an example command for compiling using g++ on Linux. Make sure to adjust the Python include path and Boost.Python library name according to your system’s configuration:

Next, write the Python code that will use the wrapped class:

Ensure that the shared library (my_module.so) is in the same directory as your Python script or in a directory that’s included in the Python module search path. Then run the script:

When you run the Python script, you should see the following output:

Here are some examples:

Here are some great examples:

The following code shows how to create a wrapper for a C++ class that uses Boost, and then calls this from a C# application. The handling of return values and exceptions are shown too:

Next, create a wrapper to expose the class to .NET:

Now create the C# application that uses the wrapper:

Compile the C++ code into a DLL:

Compile the wrapper:

Finally, create a C# project (say, using Visual Studio), add a reference to the MyClassWrapper.dll, then build and run the application:

Through the use of the Java Native Interface (JNI) or Java Native Access (JNA), developers can call Boost libraries from Java applications. It involves creating native methods in Java that are implemented in C++ and using Boost libraries as part of those implementations. Here is a simple example (without error handling or return values):

The expected remaining lifespan of the C++ programming language is generally considered to be long, probably spanning several decades. While it’s difficult to assign a precise number of years, here’s an overview of the factors contributing to this consensus:

Python is often the top recommendation due to its versatility, simplicity, and wide application in growing fields like artificial intelligence (AI), machine learning (ML), rapid prototyping, and data science. And Boost.Python is there to help you integrate with the Boost libraries. Rust is another strong contender, especially if you are interested in systems programming and are looking for reliability and security. If you see the future as more cloud computing, then Go makes a strong case for itself. And let’s not forget that so much computing is now web based, so JavaScript deserves a mention here too. All of these languages offer valuable resources that complement C++ and prepare you for an uncertain future.

There are a few advantages of using the Boost asserts, available in <boost/assert.hpp>, including that BOOST_ASSERT is fully customizable using BOOST_ENABLE_ASSERT_HANDLER, which can be used to log extra data or stack traces, and there is better integration with Boost.Test. BOOST_STATIC_ASSERT is best utilized when using older C++ standards (pre-C++17), or you are using deeply templated code. You might also prefer the Boost macros if you are engaging the features of other Boost libraries and are looking for consistent tooling. For a fuller discussion, refer to Boost Macros.

By default, BOOST_ASSERT macros are completely removed from the compiled binary when NDEBUG is defined, just like the standard assert macro. If NDEBUG is not defined a BOOST_ASSERT(x) will expand, usually to an assertion_failed() if the assert condition fails. If NDEBUG is defined it expands to ((void)0) so nothing is generated. Boost does provide the BOOST_DISABLE_ASSERTS macro, which has the same effect on Boost asserts as NDEBUG - but will leave other asserts alone.

Instead of throwing an exception when an assert fails, it is often the best practice to log the failure. For example, here is a custom assert handler using the features of Boost.Log to record the event:

An example use of this handler would be:

Use this checklist to ensure your application correctly integrates Boost libraries across Debug and Release configurations.

Here’s an example of how to set up your CMakeLists.txt to handle BOOST_ASSERT correctly by toggling behavior based on the build type (Debug or Release). The example includes linking with some sample libraries (Boost.Log, Boost.System and Boost.Thread):

Go to Boost Downloads.

The scheme is x.y.z, where x is incremented only for massive changes, such as a reorganization of many libraries, y is incremented whenever a new library is added, and z is incremented for maintenance releases. y and z are reset to 0 if the value to the left changes

No, although there is a strong informal relationship in that many members of the committee participate in Boost, and the people who started Boost were all committee members.

Some might, but that is up to the standards committee. Committee members who also participate in Boost will definitely be proposing at least some Boost libraries for standardization. Libraries which are "existing practice" are most likely to be accepted by the C++ committee for future standardization. Having a library accepted by Boost is one way to establish existing practice.

No. It is a non-profit.

File extensions communicate the "type" of the file, both to humans and to computer programs. The '.h' extension is used for C header files, and therefore communicates the wrong thing about C++ header files. Using no extension communicates nothing and forces inspection of file contents to determine type. Using .hpp unambiguously identifies it as C++ header file, and works well in practice.

Refer to the Contributor Guide. Note that shareware libraries, commercial libraries, or libraries requiring restrictive licensing are all not acceptable. Your library must be provided free, with full source code, and have an acceptable license. There are other ways of contributing too, providing feedback, testing, submitting suggestions for new features and bug fixes, for example. There are no fees for submitting a library.

Retrofitting the C++ language with memory-safe constructs has proven to be daunting. The Safe C++ proposal for a memory-safe set of operations is currently in a state of indefinite hiatus. For more information, including current safe coding practices, refer to Contributors FAQ: Safe C++. For terminology - refer to Glossary: S.

The Boost.SmartPtr library provides a set of smart pointers that helps in automatic and appropriate resource management. They are particularly useful for managing memory and provide a safer and more efficient way of handling dynamically allocated memory. The library provides the following types of smart pointers:

There are several types of smart pointers with different characteristics and use cases, so use them appropriately according to your program’s requirements. Here are some common examples:

A shared_ptr is a reference-counting smart pointer, meaning it retains shared ownership of an object through a pointer. When the last shared_ptr to an object is destroyed, the pointed-to object is automatically deleted. For example:

Note that shared_ptr objects can be copied, meaning ownership of the memory can be shared among multiple pointers. The memory will be freed when the last remaining shared_ptr is destroyed. For example:

A weak_ptr is a smart pointer that holds a non-owning ("weak") reference to an object managed by a shared_ptr. It must be converted to shared_ptr in order to access the object. For example:

A unique_ptr is a smart pointer that retains exclusive ownership of an object through a pointer. It’s similar to std::unique_ptr in the C++ Standard Library. For example:

Here, the C++ Standard Library. The Search feature is useful for locating individual components.

Most Boost libraries provide useful and advanced functionality unavailable in the Standard Library. A few Boost libraries have indeed been superseded by the Standard Library, but remain in Boost for backwards compatibility. To determine which you should use, given the choice, consider working through the following process.

Yes, currently the functionality of two Boost libraries are being considered:

C++ 2026 is slated as the next full release, for details refer to Current Status.

C++ templates are a powerful feature of the language that allows for generic programming. They enable the creation of functions or classes that can operate on different data types without having to duplicate code.

Function templates are functions that can be used with any data type. You define them using the keyword template followed by the template parameters. Function templates allow you to create a single function that can operate on different data types.

Template specialization is a feature of C++ templates that allows you to define a different implementation of a template for a specific type or set of types. It can be used with both class and function templates.

The benefits of using templates include code reusability, type safety, and the ability to use generic programming paradigms. The drawbacks include potentially increased compile times, difficult-to-understand error messages, and complexities associated with template metaprogramming.

Here’s a simple example of how you might use a function template to implement a generic sort function:

This function can now be used to sort arrays of any type (that supports the < and > operators), not just a specific type.