BDE 4.14.0 Production release
|
Provide an STL-compliant unordered_multiset container.
Canonical header: bsl_unordered_set.h
This component defines a single class template, bsl::unordered_multiset
, implementing the standard container holding a collection of possibly duplicate keys with no guarantees on ordering (unless keys have the same value).
An instantiation of unordered_multiset is an allocator-aware, value-semantic type whose salient attributes are its size (number of keys) and the set of keys the unordered_multiset contains, without regard to their order. If unordered_multiset is instantiated with a key type that is not itself value-semantic, then it will not retain all of its value-semantic qualities. It is possible to instantiate unordered_multiset with a key type that does not have an accessible copy-constructor, in which case the unordered_multiset will not be copyable. Note that the equality operator for each element is used to determine when two unordered_multiset objects have the same value, and not the equality comparator supplied at construction.
An unordered_multiset meets the requirements of an unordered associative container with forward iterators in the C++11 standard [unord]. The unordered_multiset implemented here adheres to the C++11 standard, except that it may rehash when setting the max_load_factor
in order to preserve the property that the value is always respected (which is a potentially throwing operation).
An unordered_multiset instantiation is a fully "Value-Semantic Type" (see bsldoc_glossary ) only if the supplied KEY
template parameter is fully value-semantic. It is possible to instantiate an unordered_multiset with a KEY
parameter argument that does not provide a full set of value-semantic operations, but then some methods of the container may not be instantiable. The following terminology, adopted from the C++11 standard, is used in the function documentation of unordered_multiset to describe a function's requirements for the KEY
template parameter. These terms are also defined in section [utility.arg.requirements] of the C++11 standard. Note that, in the context of an unordered_multiset instantiation, the requirements apply specifically to the unordered_multiset s element type, value_type
, which is an alias for KEY
.
X
- denotes an allocator-aware container type (unordered_multiset ) T
- value_type
associated with X
A
- type of the allocator used by X
m
- lvalue of type A
(allocator) p
- address (T *
) of uninitialized storage for a T
within an X
rv
- rvalue of type (non-const
) T
v
- rvalue or lvalue of type (possibly const
) T
args
- 0 or more arguments
The following terms are used to more precisely specify the requirements on template parameter types in function-level documentation.
default-insertable: T
has a default constructor. More precisely, T
is default-insertable
into X
means that the following expression is well-formed:
allocator_traits<A>::construct(m, p)
move-insertable: T
provides a constructor that takes an rvalue of type (non-const
) T
. More precisely, T
is move-insertable
into X
means that the following expression is well-formed:
allocator_traits<A>::construct(m, p, rv)
copy-insertable: T
provides a constructor that takes an lvalue or rvalue of type (possibly const
) T
. More precisely, T
is copy-insertable
into X
means that the following expression is well-formed:
allocator_traits<A>::construct(m, p, v)
move-assignable: T
provides an assignment operator that takes an rvalue of type (non-const
) T
.
copy-assignable: T
provides an assignment operator that takes an lvalue or rvalue of type (possibly const
) T
.
emplace-constructible: T
is emplace-constructible
into X
from args
means that the following expression is well-formed:
allocator_traits<A>::construct(m, p, args)
erasable: T
provides a destructor. More precisely, T
is erasable
from X
means that the following expression is well-formed:
allocator_traits<A>::destroy(m, p)
equality-comparable: The type provides an equality-comparison operator that defines an equivalence relationship and is both reflexive and transitive.
The (template parameter) types HASH
and EQUAL
must be copy-constructible function-objects. Note that this requirement is somewhat stronger than the requirement currently in the standard; see the discussion for Issue 2215 (http://cplusplus.github.com/LWG/lwg-active.html#2215);
HASH
shall support a function call operator compatible with the following statements:
where the definition of the called function meets the requirements of a hash function, as specified in {bslstl_hash |Standard Hash Function}.
EQUAL
shall support the a function call operator compatible with the following statements:
where the definition of the called function defines an equivalence relationship on keys that is both reflexive and transitive.
HASH
and EQUAL
function-objects are further constrained, such for any two objects whose keys compare equal by the comparator, shall produce the same value from the hasher.
The type supplied as an unordered multiset's ALLOCATOR
template parameter determines how that unordered multiset will allocate memory. The unordered_multiset template supports allocators meeting the requirements of the C++11 standard [allocator.requirements], and in addition it supports scoped-allocators derived from the bslma::Allocator
memory allocation protocol. Clients intending to use bslma
-style allocators should use the template's default ALLOCATOR
type. The default type for the ALLOCATOR
template parameter, bsl::allocator
, provides a C++11 standard-compatible adapter for a bslma::Allocator
object.
If the parameterized ALLOCATOR
type of an unordered_multiset instantiation is bsl::allocator
, then objects of that unordered multiset type will conform to the standard behavior of a bslma
-allocator-enabled type. Such an unordered multiset accepts an optional bslma::Allocator
argument at construction. If the address of a bslma::Allocator
object is explicitly supplied at construction, it will be used to supply memory for the unordered_multiset throughout its lifetime; otherwise, the unordered_multiset will use the default allocator installed at the time of the unordered_multiset s construction (see bslma_default ). In addition to directly allocating memory from the indicated bslma::Allocator
, an unordered_multiset supplies that allocator's address to the constructors of contained objects of the (template parameter) type KEY
with the bslalg::TypeTraitUsesBslmaAllocator
trait.
This section describes the run-time complexity of operations on instances of unordered_multiset :
No method of unordered_multiset invalidates a pointer or reference to an element in the unordered multiset, unless it also erases that element, such as any erase
overload, clear
, or the destructor (that erases all elements). Pointers and references are stable through a rehash.
Iterators to elements in the container are invalidated by any rehash, so iterators may be invalidated by an insert
or emplace
call if it triggers a rehash (but not otherwise). Iterators to specific elements are also invalidated when that element is erased. Note that the end
iterator is not an iterator referring to any element in the container, so may be invalidated by any non-const
method.
The unordered multiset has interfaces that can provide insight into and control of its inner workings. The syntax and semantics of these interfaces for bslstl_unorderedmultiset are identical to those of bslstl_unorderedmap . See the discussion in {bslstl_unorderedmap |Unordered Map Configuration} and the illustrative material in {bslstl_unorderedmap |Example 2}.
An important factor in the performance of an unordered multiset (and any of the other unordered containers) is the choice of hash function. Please see the discussion in {bslstl_unorderedmap |Practical Requirements on HASH
}.
In this section we show intended use of this component.
Unordered sets are useful in situations when there is no meaningful way to order key values, when the order of the values is irrelevant to the problem domain, and (even if there is a meaningful ordering) the value of ordering the results is outweighed by the higher performance provided by unordered sets (compared to ordered sets).
One uses a multiset (ordered or unordered) when there may be more than one instance of an element of a set and when that multiplicity must be preserved.
Note that the data type described below is an augmentation of that used in {bslstl_unorderedset |Example 1}. The data itself (randomly generated) is different.
Suppose one is analyzing data on a set of customers, and each customer is categorized by several attributes: customer type, geographic area, and (internal) project code; and that each attribute takes on one of a limited set of values. Additionally, there is some financial data associated with each customer: past sales and pending sales.
The several customer attributes are modeled by several enumerations:
For printing these values in a human-readable form, we define these helper functions:
The data set (randomly generated for this example) is provided in a statically initialized array:
Suppose, as a step in analysis, we wish to determine the average of the past sales and the average of the pending sales for each customer for each unique combination of customer attributes (i.e., for each customer profile in the data set). To do so, we must aggregate our data items by customer profile but also retain the unique financial data for each item. The bslstl_unorderedmultiset provides those semantics.
First, as there are no standard methods for hashing or comparing our user- defined types, we define CustomerDatumHash
and CustomerDatumEqual
classes, each a stateless functor. Note that there is no meaningful ordering of the attribute values, they are merely arbitrary code numbers; nothing is lost by using an unordered multiset instead of an ordered multiset:
Notice that many of the required methods of the hash and comparator types are compiler generated. (The declaration of those methods are commented out and suffixed by an = default
comment.)
Also notice that the boolean operation provided by CustomerDatumEqual
is more properly thought of as "equivalence", not "equality". There may be more than one data item with the same customer profile (i.e., the same for our purpose here), but they have distinct financial data so the two items are not equal (unless the financial data also happens to match).
Next, we define the type of the unordered multiset and a convenience aliases:
Now, create a helper function to calculate the average financials for a category of customer profiles within the unordered multiset.
Then, we create an unordered multiset and insert each item of data
.
Finally, to calculate the statistics we need, we must detect the transition between categories as we iterate through customerInfoData
.
We find on standard output: