History and reasons to use Boost.Container

Boost.Container is a product of a long development effort that started in 2004 with the experimental Shmem library, which pioneered the use of standard containers in shared memory. Shmem included modified SGI STL container code tweaked to support non-raw allocator::pointer types and stateful allocators. Once reviewed, Shmem was accepted as Boost.Interprocess and this library continued to refine and improve those containers.

In 2007, container code from node containers (map, list, slist) was rewritten, refactored and expanded to build the intrusive container library Boost.Intrusive. Boost.Interprocess containers were refactored to take advantage of Boost.Intrusive containers and code duplication was minimized. Both libraries continued to gain support and bug fixes for years. They introduced move semantics, emplacement insertion and more features of then unreleased C++0x standard.

Boost.Interprocess containers were always standard compliant, and those containers and new containers like stable_vector and flat_[multi]set/map were used outside Boost.Interprocess with success. As containers were mature enough to get their own library, it was a natural step to collect them containers and build Boost.Container, a library targeted to a wider audience.

Why Boost.Container?

With so many high quality standard library implementations out there, why would you want to use Boost.Container? There are several reasons for that:

Even if you have a earlier standard conforming compiler, you still can have access to many of the latest C++ standard features and have an easy code migration when you change your compiler.
It's compatible with Boost.Interprocess shared memory allocators.
You have extremely useful new containers like [stable/static/small]_vector and flat_[multi]set/map.
If you work on multiple platforms, you'll have a portable behaviour without depending on the std-lib implementation conformance of each platform. Some examples:
- Default constructors don't allocate memory at all, which improves performance and usually implies a no-throw guarantee (if predicate's or allocator's default constructor doesn't throw).
- Small string optimization for basic_string.
Extended functionality beyond the standard based on user feedback to improve code performance.
You need a portable implementation that works when compiling without exceptions support or you need to customize the error handling when a container needs to signal an exceptional error.

History and reasons to use Boost.Container

Boost.Container history

Why Boost.Container?