| Home | Libraries | People | FAQ | More

## 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)`).