Extended functionality: Basic extensions

Default initialization for vector-like containers

STL and most other containers value initialize new elements in common operations like vector::resize(size_type n) or explicit vector::vector(size_type n).

In some performance-sensitive environments, where vectors are used as a replacement for variable-size buffers for file or network operations, value initialization is a cost that is not negligible as elements are going to be overwritten by an external source shortly after new elements are added to the container.

Boost.Container offers two new members for vector, static_vector and stable_vector: explicit container::container(size_type n, default_init_t) and container::resize(size_type n, default_init_t), where new elements are constructed using default initialization.

Ordered range insertion for associative containers (ordered_unique_range, ordered_range)

When filling associative containers big performance gains can be achieved if the input range to be inserted is guaranteed by the user to be ordered according to the predicate. This can happen when inserting values from a set to a multiset or between different associative container families ([multi]set/map vs. flat_[multi]set/map).

Boost.Container has some overloads for constructors and insertions taking an ordered_unique_range_t or an ordered_range_t tag parameters as the first argument. When an ordered_unique_range_t overload is used, the user notifies the container that the input range is ordered according to the container predicate and has no duplicates. When an ordered_range_t overload is used, the user notifies the container that the input range is ordered according to the container predicate but it might have duplicates. With this information, the container can avoid multiple predicate calls and improve insertion times.

Constant-time range splice for `(s)list`

In the first C++ standard list::size() was not required to be constant-time, and that caused some controversy in the C++ community. Quoting Howard Hinnant's On List Size paper:

There is a considerable debate on whether std::list<T>::size() should be O(1) or O(N). The usual argument notes that it is a tradeoff with:

splice(iterator position, list& x, iterator first, iterator last);

If size() is O(1) and this != &x, then this method must perform a linear operation so that it can adjust the size member in each list

C++11 definitely required size() to be O(1), so range splice became O(N). However, Howard Hinnant's paper proposed a new splice overload so that even O(1) list:size() implementations could achieve O(1) range splice when the range size was known to the caller:

void splice(iterator position, list& x, iterator first, iterator last, size_type n);

Effects: Inserts elements in the range [first, last) before position and removes the elements from x.

Requires: [first, last) is a valid range in x. The result is undefined if position is an iterator in the range [first, last). Invalidates only the iterators and references to the spliced elements. n == distance(first, last).

Throws: Nothing.

Complexity: Constant time.

This new splice signature allows the client to pass the distance of the input range in. This information is often available at the call site. If it is passed in, then the operation is constant time, even with an O(1) size.

Boost.Container implements this overload for list and a modified version of it for slist (as slist::size() is also O(1)).

The void allocator argument

Allocator template argument is void
Allocator with void value type

Boost.Container treats void specially in the allocator template argument in two related ways, so that the container's allocator_type always has the correct value_type. This applies to sequence and associative containers alike (including map, where the rebound value_type is std::pair<const Key, T>).

Allocator template argument is void

When the allocator argument is the type void, the library selects its default allocator for the container's value_type.

Allocator with void value type

Standard containers typically require the allocator's value_type to match the container's element type, which forces repeating that type in every declaration:

boost::container::vector<MyType, MyAlloc<MyType> > v;
boost::container::map   <Key, T, Compare, MyAlloc< std::pair<const Key, T> > > m;

Boost.Container also accepts an allocator whose value_type is void, so that those types can be used as type-erased allocators. The container's allocator_type is the rebound allocator.

#include <boost/container/vector.hpp>
#include <boost/container/map.hpp>
#include <boost/container/allocator.hpp>
#include <boost/container/pmr/polymorphic_allocator.hpp>
#include <utility>
#include <type_traits>


int main()
{
   using namespace boost::container;

//
// void as Allocator template argument
//
   //Allocator argument is void: the library selects its default allocator.
   vector<int>       v_default;          // Allocator defaults to void
   vector<int, void> v_explicit_void;    // Explicit void
   map<int, double>  m_default;          // Allocator defaults to void
   map<int, double, std::less<int>, void> m_explicit_void;

   //Same types
   v_default.push_back(1);
   v_explicit_void = v_default;

   m_default[3] = 3.0;
   m_explicit_void = m_default;

//
// Automatic rebinding with allocator::value_type == void, 
//
   typedef pmr::polymorphic_allocator<void>              pmr_void_t;
   typedef vector<int, pmr_void_t >                      vector_alloc_of_void_t;
   typedef map<int, double, std::less<int>, pmr_void_t > map_alloc_of_void_t;
   typedef std::pair<const int, double>                  map_value_t;


   //Container::allocator_type is the expected type
   static_assert
      (std::is_same< vector_alloc_of_void_t >::allocator_type, pmr::polymorphic_allocator<int> >::value);
   static_assert
      (std::is_same< map_alloc_of_void_t >::allocator_type, pmr::polymorphic_allocator<map_value_t> >::value);

   //Usually the Allocator<void> type is convertible to the rebound allocator, no need
   //to explicitly rebind it.
   pmr_void_t alloc;
   vector_alloc_of_void_t v(alloc);
   map_alloc_of_void_t m(std::less<int>(), alloc);

   return 0;
}

Benefits. Accepting void-valued allocators has several advantages:

The element type is written once. In vector<MyType, MyAlloc<MyType> > the element type appears twice and both occurrences must be kept in sync.
It avoids a whole class of value_type mismatches in associative containers, where the required allocator value_type is not the obvious one and is not even the same across container families: map requires MyAlloc< std::pair<const Key, T> > (note the const) whereas flat_map requires MyAlloc< std::pair<Key, T> > (no const). Writing MyAlloc<void> is correct for both.
It removes rebinding boilerplate from generic code. Code that is parameterized on an allocator and instantiates containers of several element types no longer needs to explicitly rebind, the allocator can be forwarded as a single template argument.

Rebinding happens entirely at compile time, so there is no runtime cost. Since the container's allocator_type is the rebound allocator, so AllocatorAwareContainer semantics (propagation traits, get_allocator(), allocator-extended constructors) are unchanged.